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

docs: add feature maps, audits, research, plans lots 19-26

Browse Source 
- Feature maps: agentic intelligence, digital factory, yiacad global/UI/UX/backend
- Audits: consolidation, refactor manifest, exhaustive refonte
- Research: OSS AI-native CAD, digital factory stack, mascarade observability
- Plans: lots 19-26 (mesh tri-repo, UI/UX refonte, yiacad global,
  intelligence agentique, mistral agents/studio, hypnoled, EDA AI tools,
  git EDA platform)
- Operator docs: machine registry, alignment, sync status, provider compat
- Mascarade/Kill_LIFE product contracts and OPS bridge
- PCB AI fab integration map, artifact WMS index
- References directory

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
L'électron rare
2026-03-24 00:20:32 +01:00
parent 86f46c8a64
commit 066acde0cb
94 changed files with 10458 additions and 350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-21.md
+66
View File
@@ -0,0 +1,66 @@
# Feature map - integration intelligence agentique (2026-03-21)
## Vue d'ensemble
```mermaid
mindmap
root((Intelligence Program))
Sources de verite
Audit consolidation
Spec integration intelligence
Plan 22
TODO 22
Veille OSS
Cockpit
intelligence_tui
compatibility alias
refonte_tui bridge
logs
memory latest
next actions
purge
contrat cockpit-v1
Gouvernance agents
PM-Mesh
Docs-Research
Studio-Product
Mesh-Contracts
Operator-Lane
Runtime-Companion
QA-Compliance
OSS-Watch
Integrations IA
MCP
LangGraph
OpenAI Agents SDK
Roo Code patterns
OpenHands packaging
Extensions
Studio
Mesh
Operator
```
## Carte fonctionnelle
```mermaid
flowchart LR
Docs["README / docs/index / AI_WORKFLOWS"] --> TUI["intelligence_tui.sh"]
Plans["Plan 22 / TODO 22 / plan agents"] --> TUI
Research["WEB_RESEARCH_OPEN_SOURCE"] --> TUI
Tasks["specs/04_tasks.md"] --> TUI
TUI --> Logs["artifacts/cockpit/intelligence_program/*.log"]
TUI --> Memory["latest.json + latest.md"]
TUI --> JSON["status --json (cockpit-v1)"]
JSON --> Automation["automation / scripts / CI locale"]
TUI --> Refonte["refonte_tui.sh --action intelligence-*"]
```
## Priorites de livraison
1. surface TUI + logs + contrat JSON
2. memoire + next-actions
3. plan/todo/owners a jour
4. veille 2026 exploitable
5. raccord docs index + README cockpit
6. tests de contrat
docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-22.md
+31
View File
@@ -0,0 +1,31 @@
# Agentic intelligence feature map (2026-03-22)
## Scope
This map covers the current 2026 intelligence lane across docs, cockpit, YiACAD native CAD, and the `web/` Git EDA platform.
```mermaid
flowchart LR
Docs["Spec + plans + TODOs"] --> TUI["intelligence_tui"]
TUI --> Memory["latest.json / latest.md"]
TUI --> Scorecard["scorecard"]
TUI --> Reco["recommendations"]
Memory --> Gateway["runtime_ai_gateway"]
Web["web/ Next.js + GraphQL"] --> Review["PR review + dashboard + PCB viewer"]
Realtime["Yjs + websocket"] --> Review
Workers["BullMQ + EDA workers"] --> Review
Git["Git source of truth"] --> Review
AI["MCP / service-first AI overlay"] --> Review
AI --> TUI
```
## Feature lanes
| Lane | Current state | Next meaningful lot |
| --- | --- | --- |
| Contracts | `cockpit-v1`, `summary-short/v1`, `runtime-mcp-ia-gateway/v1` are live | stabilize the canonical source matrix and artifact cadence |
| Intelligence TUI | status, memory, scorecard, comparison, recommendations | surface `plan 23` and web runtime signals |
| Native YiACAD CAD | KiCad/FreeCAD shells, backend service-first, review center | deeper compiled UI and richer direct backend hooks |
| Web Git EDA | buildable scaffold, GraphQL, Yjs transport, BullMQ worker | real Git read model, live artifacts, Yjs scene binding |
| Review assist | not yet productized | read-only hints from changed files, ERC/DRC, ops summary |
| MCP/service tools | tracked in docs/backlog | formalize parts, CI, artifact and review tool boundaries |
docs/AGENTIC_LANDSCAPE.md
+98 -20
View File
@@ -1,23 +1,101 @@
# Agentic landscape (appliqué à KiCad)
# Agentic Landscape (Kill_LIFE)
- Spec-driven backbone: Spec Kit citeturn0search2
- Standards injection: Agent OS (standards versionnés + profils) citeturn0search3
- Role workflows + gates: BMAD-METHOD
- Tool-first runtime (local): Agent Zero
- Native operator runtime: ZeroClaw CLI/gateway on the operator machine
- Optional orchestration overlay: LangGraph around ZeroClaw
- Interop tools: MCP local en `stdio` via le runtime `kicad-mcp`
## Posture de départ
Posture operateur retenue:
- `ZeroClaw` reste un runtime local demarrable a la demande.
- `LangGraph`, `AutoGen` et `n8n` restent des overlays/runbooks autour de ce runtime.
- `zeroclaw.saillant.cc` sert la surface live du runtime natif quand il est demarre.
- `zeroclaw-docs.saillant.cc` et `langgraph.saillant.cc` servent les runbooks operateur derriere le proxy.
- Le fallback provider `OpenRouter` est valide en runtime sur le gateway natif.
- Spec-driven backbone: `specs/*` et `specs/constraints.yaml`
- Standards and gates: `compliance/*`, `bmad/*`
- Runtime local: `ZeroClaw` + MCP + `crazy_life` comme éditeur
- Overlays: `LangGraph`, `AutoGen`, `n8n` en option contrôlée
- Exécution locale de préférence, GitHub pour la traçabilité distante
Le repo fournit :
- `specs/` pour la source de vérité
- `standards/` pour les conventions hardware/firmware
- `bmad/` pour les gates
- `tools/hw/*` pour une exécution locale reproductible
- `hardware_previews.yml` pour des previews PR et un evidence pack
```mermaid
flowchart TD
Inputs[Issue / PR / demande humaine] --> Labels[Labels ai:* + Scope]
Labels --> Router{Routeur d’exécution}
Router --> SpecPath[specs/ (00->04)]
Router --> GitHubPath[workflow local / GitHub dispatch]
SpecPath --> Validation{specs + compliance}
Validation --> Tools[tools/*]
Tools --> RepoTools[repo_state + compliance + auto_check_ci_cd]
Tools --> MCP[tools/hw/* + MCP launchers]
Tools --> TUI[tools/cockpit/refonte_tui.sh]
Tools --> CADFusion[tools/cad/yiacad_fusion_lot.sh]
CADFusion --> CadEvidence[Evidence CAD (cad-fusion)]
MCP --> Evidence[Evidence packs locaux]
RepoTools --> Evidence
CadEvidence --> Evidence
TUI --> Logs[artifacts/refonte_tui/*.log]
Logs --> Evidence
Evidence --> Audit[docs/evidence/*]
GitHubPath --> CI[.github/workflows/*]
CI --> Audit
Audit --> PM[PM + Plan]
PM --> Handoff[Handoffs / Plans / Labels]
Handoff --> Agents[agents/ + .github/agents/ + prompts]
```
## Modèle de fonctionnement
- `agents/` et `.github/agents/` définissent les compétences minimales.
- `tools/cockpit/refonte_tui.sh` est la surface de pilotage texte (status, logs, lot-chain).
- `ZeroClaw` reste le runtime local d’orchestration, sans remplacer la source de vérité.
- Les surfaces MCP sont locales par défaut, `huggingface` en option distante officielle.
- Les preuves et traces sont obligatoires pour les lots de refonte.
## Décisions de refonte actives
- pas de dépendance forte externe pour les lanes essentielles,
- tout overlay IA passe par une validation de sécurité (labels, scope, denylist),
- priorité à la reproductibilité documentaire (`specs`, `plans`, `diagrams`, `evidence`).
## Delta mesh 2026-03-20
Le paysage agentique du projet opere desormais comme un overlay de gouvernance maillée sur trois repos, avec neuf agents principaux.
| Agent | Repo owner prefere | Responsabilite |
| --- | --- | --- |
| `PM-Mesh` | `Kill_LIFE` | backlog tri-repo, priorisation, ordre de propagation |
| `Arch-Mesh` | `Kill_LIFE` | contrats inter-repos, ADR, compatibilite |
| `Embedded-CAD` | `Kill_LIFE` | firmware, hardware, evidence embarquee |
| `Runtime-Companion` | `mascarade` | runtime IA, providers, adaptateurs MCP |
| `CAD-Fusion` | `Kill_LIFE` | pilote YiACAD, health CAD, preuve et rollback |
| `Web-Cockpit` | `crazy_life` | UI cockpit, workflow editor, supervision |
| `QA-Compliance` | transversal | matrices, smokes, preuves |
| `Docs-Research` | transversal | README, specs, Mermaid, benchmark OSS |
| `SyncOps` | `Kill_LIFE` | SSH, repo-state, TUI, logs, sync continue |
Sous-agents standardises:
- `Lot-Planner`, `Risk-Triager`
- `Schema-Guard`, `Compat-Auditor`
- `Firmware-Lane`, `CAD-Lane`, `CAD-Fusion`
- `Provider-Bridge`, `Runtime-Smoke`
- `UI-Flow`, `Schema-Consumer`
- `Spec-Mirror`, `Evidence-Pack`
- `Mermaid-Map`, `OSS-Benchmark`
- `SSH-Health`, `Log-Ops`
Skills opératoires actives:
- `bash-cli-tui`: `SyncOps`, `CAD-Fusion`, `Doc-Runbook`
- `playwright`: `Web-Cockpit` quand une validation UI réelle devient nécessaire
- `OSS-Benchmark`: `Docs-Research`, `CAD-Fusion`
- `Evidence-Pack`: `QA-Compliance`, `Docs-Research`
Routing prioritaire des lots ouverts:
- `PM-Mesh` garde `T-RE-204` comme lot exécutable bloquant.
- `CAD-Fusion` tient la lane parallèle `T-RE-209` / `T-RE-210`.
- `SyncOps` publie la synthèse hebdomadaire et la checklist de sortie (`T-RE-301` / `T-RE-304`).
Regle de coexistence: nous ne sommes pas seuls dans le codebase; toute intervention doit rester dans un `write_set` declare et observable.
Matrice detaillee publiee: `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
Delta d'execution machine-readable:
- `Schema-Guard` publie des schemas JSON versionnes pour `agent_handoff`, `repo_snapshot`, `workflow_handshake`.
- `Runtime-Smoke` et `Schema-Consumer` consomment ces contrats depuis la lane soeur `Kill_LIFE-main` au moment des preflights compagnons.
- La validation CI visible du handshake passe desormais par `.github/workflows/mesh_contracts.yml`.
docs/AGENT_MODULE_ASSIGNMENTS_2026-03-20.md
+7
View File
@@ -0,0 +1,7 @@
# Alias documentaire
Le document canonique est:
- `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
Ce fichier reste un alias pour compatibilite documentaire temporaire afin d'eviter deux sources de verite concurrentes.
docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md
+162
View File
@@ -0,0 +1,162 @@
# Matrice agentique spec/module tri-repo
Last updated: 2026-03-22 14:30 CET
## Regles d'affectation
- Une specification ou un module = un `owner_agent`, un `sub_agent`, un `write_set` et une preuve attendue.
- Les surfaces cross-repo et hors-repo sont `single-writer`.
- Les write-sets restent disjoints par lot.
- Les lanes mesh `*-main` sont les seules lanes de propagation.
- `cils` reste sous garde `cils-lockdown` pour les surfaces non critiques.
```mermaid
flowchart LR
PM[PM-Mesh] --> KL[Kill_LIFE specs + workflows]
PM --> DOC[Docs-Research]
ARCH[Arch-Mesh] --> MCP[Runtime + contracts]
ARCH --> CAD[Embedded-CAD]
WEB[Web-Cockpit] --> UI[crazy_life UI + gateway]
RUN[Runtime-Companion] --> MAS[mascarade core + bridge]
OPS[SyncOps] --> TUI[TUI + logs + SSH + dirty-set]
QA[QA-Compliance] --> CI[CI + schemas + release gates]
DOC --> KL
MAS --> UI
UI --> KL
OPS --> MAS
OPS --> UI
QA --> MAS
QA --> UI
```
## Kill_LIFE - specifications
| Specification | Owner agent | Sub-agent | Competences / skills | Write-set principal |
| --- | --- | --- | --- | --- |
| `specs/00_intake.md` | `PM-Mesh` | `Intake-Guard` | cadrage, triage, backlog | `specs/00_intake.md` |
| `specs/01_spec.md` | `Arch-Mesh` | `Requirements-Lead` | exigences, AC, frontieres | `specs/01_spec.md` |
| `specs/02_arch.md` | `Arch-Mesh` | `Contract-Guard` | architecture, ADR, compat | `specs/02_arch.md` |
| `specs/03_plan.md` | `PM-Mesh` | `Plan-Orchestrator` | sequencing, dependances, lots | `specs/03_plan.md` |
| `specs/04_tasks.md` | `PM-Mesh` | `Todo-Tracker` | execution, preuve, priorisation | `specs/04_tasks.md` |
| `specs/constraints.yaml` | `QA-Compliance` | `Constraint-Gate` | gates, invariants, drift control | `specs/constraints.yaml` |
| `specs/README.md` | `Docs-Research` | `Spec-Index` | navigation, source of truth | `specs/README.md` |
| `specs/knowledge_base_mcp_spec.md` | `Runtime-Companion` | `KB-MCP` | MCP, degraded-safe runtime | `specs/knowledge_base_mcp_spec.md` |
| `specs/github_mcp_conversion_spec.md` | `Runtime-Companion` | `Dispatch-MCP` | GitHub dispatch, runtime bridge | `specs/github_mcp_conversion_spec.md` |
| `specs/ci_cd_spec.md` | `QA-Compliance` | `CI-Gate` | CI, release gates, evidence packs | `specs/ci_cd_spec.md` |
| `specs/agentic_intelligence_integration_spec.md` | `PM-Mesh` | `Plan-Orchestrator` | gouvernance intelligence, contrats courts, lanes TUI | `specs/agentic_intelligence_integration_spec.md` |
| `specs/mcp_agentics_target_backlog.md` | `Runtime-Companion` | `MCP-Orchestrator` | backlog MCP, orchestration agentique | `specs/mcp_agentics_target_backlog.md` |
| `specs/mcp_tasks.md` | `Runtime-Companion` | `MCP-Orchestrator` | plan d'execution MCP, checklist | `specs/mcp_tasks.md` |
| `specs/kicad_mcp_scope_spec.md` | `Embedded-CAD` | `CAD-Bridge` | KiCad MCP, host-first CAD | `specs/kicad_mcp_scope_spec.md` |
| `specs/zeroclaw_dual_hw_orchestration_spec.md` | `Embedded-CAD` | `ZeroClaw-Orchestrator` | hardware orchestration, smokes | `specs/zeroclaw_dual_hw_orchestration_spec.md` |
| `specs/zeroclaw_dual_hw_todo.md` | `Embedded-CAD` | `ZeroClaw-Orchestrator` | firmware backlog, execution lot | `specs/zeroclaw_dual_hw_todo.md` |
| `specs/yiacad_uiux_apple_native_spec.md` | `UX-Lead` | `Apple-HIG` | Apple-native UX, CAD shell | `specs/yiacad_uiux_apple_native_spec.md` |
| `specs/yiacad_git_eda_platform_spec.md` | `Web-CAD-Platform` | `Project-Service` | Git-first EDA product, GraphQL, workers, review, multi-tenant path | `specs/yiacad_git_eda_platform_spec.md` |
| `specs/cad_modeling_tasks.md` | `Embedded-CAD` | `CAD-Smoke` | CAD tasking, modeling workflow | `specs/cad_modeling_tasks.md` |
| `specs/mesh_contracts.md` | `Arch-Mesh` | `Mesh-Contracts` | tri-repo contract, handoffs | `specs/mesh_contracts.md` |
| `specs/contracts/agent_handoff.schema.json` | `Schema-Guard` | `Handoff-Schema` | schema versioning, strict contract | `specs/contracts/agent_handoff.schema.json` |
| `specs/contracts/repo_snapshot.schema.json` | `Schema-Guard` | `Snapshot-Schema` | repo-state, snapshot contract | `specs/contracts/repo_snapshot.schema.json` |
| `specs/contracts/workflow_handshake.schema.json` | `Schema-Guard` | `Workflow-Schema` | workflow handshake, compat UI/API | `specs/contracts/workflow_handshake.schema.json` |
| `specs/contracts/operator_lane_evidence.schema.json` | `Schema-Guard` | `Evidence-Schema` | E2E evidence, operator lane | `specs/contracts/operator_lane_evidence.schema.json` |
## Kill_LIFE - modules
| Module | Owner agent | Sub-agent | Competences / skills | Write-set principal |
| --- | --- | --- | --- | --- |
| `tools/cockpit/*` | `SyncOps` | `TUI-Ops` | `bash-cli-tui`, SSH, logs, runbooks | `tools/cockpit/*` |
| `tools/cad/*` | `Embedded-CAD` | `CAD-UX` | host-first CAD, native hooks, review/sync ops | `tools/cad/*` |
| `tools/ai/*` | `Runtime-Companion` | `Agent-Orchestrator` | runtime AI, orchestration, provider bridges | `tools/ai/*` |
| `tools/hw/*` | `Embedded-CAD` | `CAD-Bridge` | KiCad, FreeCAD, MCP, exports, smoke | `tools/hw/*` |
| `tools/ops/*` | `Runtime-Companion` | `Provider-Bridge` | live provider bridge, smoke E2E | `tools/ops/*` |
| `tools/repo_state/*` | `SyncOps` | `Repo-State` | repo refresh, machine memory | `tools/repo_state/*` |
| `tools/specs/*` | `Schema-Guard` | `Spec-Mirror` | schema checks, mirror sync | `tools/specs/*` |
| `web/app/*` | `Web-CAD-Platform` | `Product-Web` | Next.js routes, dashboard, review, product shell | `web/app/*` |
| `web/components/*` | `Web-CAD-Platform` | `Review-Assist` | Excalidraw, KiCanvas, PR review, diff UX | `web/components/*` |
| `web/lib/graphql/*`, `web/lib/project-store.ts`, `web/lib/types.ts` | `Web-CAD-Platform` | `Project-Service` | GraphQL, Git read model, project metadata, contracts | `web/lib/graphql/*`, `web/lib/project-store.ts`, `web/lib/types.ts` |
| `web/lib/eda-queue.ts`, `web/lib/ci-enqueue.ts`, `web/workers/*` | `Web-CAD-Platform` | `EDA-CI-Orchestrator` | BullMQ, Redis, KiCad/KiBot/KiAuto worker orchestration | `web/lib/eda-queue.ts`, `web/lib/ci-enqueue.ts`, `web/workers/*` |
| `web/realtime/*` | `Web-CAD-Platform` | `Realtime-Collab` | Yjs, CRDT, websocket, presence, persistence | `web/realtime/*` |
| `web/project/*`, `web/public/vendor/*` | `Web-CAD-Platform` | `Artifacts-Bridge` | demo fixtures, artifacts, vendored viewers, sample state | `web/project/*`, `web/public/vendor/*` |
| `hardware/*` | `Embedded-CAD` | `HW-BOM` | hardware assets, BOM, DRC, previews | `hardware/*` |
| `firmware/*` | `Firmware` | `FW-Build` | PlatformIO, firmware loop, evidence | `firmware/*` |
| `compliance/*` | `QA-Compliance` | `Constraint-Gate` | standards, evidence, quality gates | `compliance/*` |
| `openclaw/*` | `Runtime-Companion` | `Sandbox-Guard` | safe automation, labels, scope guard | `openclaw/*` |
| `agents/*` + `.github/agents/*` | `Docs-Research` | `Agent-Catalog` | role docs, ownership, onboarding | `agents/*`, `.github/agents/*` |
| `.github/prompts/*` | `PM-Mesh` | `Prompt-Registry` | orchestration prompts, handoff prompts | `.github/prompts/*` |
| `workflows/*` | `KillLife-Bridge` | `Workflow-Editor` | workflow contracts, operator lane | `workflows/*` |
| `.github/workflows/*` | `QA-Compliance` | `Release-Gates` | CI, static checks, contract gates | `.github/workflows/*` |
| `docs/plans/*` | `Docs-Research` | `Plan-Recorder` | plan memory, ownership, priorities | `docs/plans/*` |
| `docs/*manifest*`, `docs/*LANDSCAPE*`, `docs/*FEATURE*` | `Docs-Research` | `Mermaid-Map` | narrative docs, feature maps | `docs/REFACTOR_MANIFEST_2026-03-20.md`, `docs/AGENTIC_LANDSCAPE.md`, `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md` |
| `docs/index.md`, `docs/QUICKSTART.md`, `docs/RUNBOOK.md` | `Docs-Research` | `Doc-Entry` | entry docs, operator navigation, discoverability | `docs/index.md`, `docs/QUICKSTART.md`, `docs/RUNBOOK.md` |
| `docs/CAD_AI_NATIVE_*`, `docs/YIACAD_*` | `UX-Lead` | `UI-Research` | Apple-native UX, runbooks, insertion points | `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`, `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`, `docs/YIACAD_*` |
| `.runtime-home/cad-ai-native-forks/kicad-ki/*` | `Embedded-CAD` | `KiCad-Native` | wx, AUI, tool actions, shell natif | `.runtime-home/cad-ai-native-forks/kicad-ki/*` |
| `.runtime-home/cad-ai-native-forks/freecad-ki/*` | `Embedded-CAD` | `FreeCAD-Native` | Qt, workbench, dock windows, shell natif | `.runtime-home/cad-ai-native-forks/freecad-ki/*` |
## `mascarade-main` - workstreams
| Workstream | Owner agent | Sub-agent | Competences / skills | Write-set principal |
| --- | --- | --- | --- | --- |
| `WS0 Gouvernance / sync` | `SyncOps` | `Docs-Research` | publication, merge preflight, hub | `README.md`, `plan.md`, `docs/EXECUTION_HUB.md`, `scripts/merge_preflight.sh` |
| `WS1 Core routing/providers` | `Runtime-Companion` | `Provider-Bridge` | providers, routing, metrics | `core/mascarade/router/**`, `load_balancer/**`, `provider_admin.py` |
| `WS2 Core agents/orchestrator` | `Runtime-Companion` | `Agent-Orchestrator` | orchestration, conversation, dispatch | `core/mascarade/agents/**`, `orchestrator/**`, `dispatch/**` |
| `WS3 Cluster / P2P` | `SyncOps` | `Mesh-Cluster` | P2P, topology, host review | `core/mascarade/p2p/**`, `core/scripts/p2p/**`, `cluster.py` |
| `WS4 Node engine` | `Arch-Mesh` | `Graph-Engine` | graph workflow, type mirror | `core/mascarade/node_engine/**`, `api/src/types/node-engine.ts`, `api/src/routes/nodes.ts` |
| `WS5 API gateway` | `Runtime-Companion` | `Gateway-Contracts` | API auth, routes, proxy core | `api/src/**` hors `killlife.ts` et `node-engine.ts` |
| `WS6 Kill_LIFE bridge` | `KillLife-Bridge` | `Evidence-Runner` | cross-repo workflow/evidence bridge | `api/src/lib/killlife.ts`, `api/src/routes/killlife.ts`, `docker-compose.yml` |
| `WS7 Web cockpit bridge` | `Web-Cockpit` | `Ops-Views` | bridge web, snapshots, operator views | `web/src/**` hors `KillLife*`, `api/public/**` |
| `WS8 Deploy / ops stack` | `SyncOps` | `Compose-Generator` | compose, services, deploy, observability | `docker-compose.yml`, `deploy/**`, `scripts/lib.sh`, `scripts/services.sh`, `scripts/compose.sh`, `scripts/modules/**` |
| `WS9 Finetune / training` | `Runtime-Companion` | `Finetune-Ops` | datasets, finetune, batch runner | `finetune/**`, `training/**`, `core/scripts/finetune/**` |
## `crazy_life-main` - workstreams
| Workstream | Owner agent | Sub-agent | Competences / skills | Write-set principal |
| --- | --- | --- | --- | --- |
| `WS-01 Shell-nav` | `Web-Cockpit` | `UI-Flow` | shell UI, routing, layout | `src/main.tsx`, `src/App.tsx`, `src/components/layout/**` |
| `WS-02 Auth-theme-config` | `Web-Cockpit` | `UI-Theme` | auth, providers settings, design system | `src/index.css`, `src/components/ui/**`, `src/auth/**`, `src/pages/Settings.tsx` |
| `WS-03 Core AI/operator` | `Web-Cockpit` | `UI-Flow` | dashboard, agents, orchestrate | `src/pages/Dashboard.tsx`, `src/pages/Agents.tsx`, `src/pages/Orchestrate.tsx`, `src/api/agents.ts` |
| `WS-04 Ops/observability` | `Web-Cockpit` | `Log-Ops` | logs, metrics, infrastructure, ops hub | `src/pages/OpsHub.tsx`, `src/pages/Logs.tsx`, `src/pages/Metrics.tsx`, `src/pages/Infrastructure.tsx`, `src/api/ops.ts` |
| `WS-05 Integrations externes` | `Web-Cockpit` | `Schema-Consumer` | knowledge base, ComfyUI, external bridges | `src/pages/KnowledgeBrowser.tsx`, `src/pages/ComfyUI.tsx`, `src/api/knowledgeBase.ts`, `src/api/comfyui.ts` |
| `WS-06 Crazy Lane UI` | `Web-Cockpit` | `Schema-Consumer` | Crazy Lane, workflow editor UI | `src/pages/CrazyLane.tsx`, `src/pages/CrazyLaneEditor.tsx`, `src/api/killlife.ts` |
| `WS-07 Gateway core` | `Web-Cockpit` | `Gateway-Core` | Hono gateway, auth, proxy allowlist | `api/src/index.ts`, `api/src/index.test.ts` |
| `WS-08 Kill_LIFE backend lane` | `KillLife-Bridge` | `Schema-Consumer` | backend lane, operator bridge, evidence | `api/src/routes/killlife.ts`, `api/src/lib/killlife.ts`, `api/src/routes/killlife.integration.test.ts`, `api/src/lib/killlife.test.ts` |
| `WS-09 Build/release/deploy` | `SyncOps` | `Release-Gates` | package/build/deploy/release | `package.json`, `api/package.json`, `Dockerfile`, `docker-compose.local.yml`, `deploy/**`, `scripts/**`, `.github/workflows/**` |
| `WS-10 Docs/contracts` | `Docs-Research` | `Mermaid-Map` | operator docs, publish flow, lot split | `README.md`, `plan.md`, `docs/**` |
| `WS-11 Legacy quarantine` | `Web-Cockpit` | `Quarantine-Guard` | legacy freeze, drift prevention | `src/pages/KillLifeWorkflows.tsx`, `src/pages/KillLifeWorkflowEditor.tsx` |
## Hotspots `single-writer`
- `Kill_LIFE`: `tools/cockpit/mesh_sync_preflight.sh`, `tools/cockpit/full_operator_lane.sh`, `workflows/embedded-operator-live.json`.
- `mascarade-main`: `api/src/lib/killlife.ts`, `api/src/routes/killlife.ts`, `docker-compose.yml`, `scripts/mesh_runtime_preflight.sh`.
- `crazy_life-main`: `api/src/index.ts`, `api/src/lib/killlife.ts`, `api/src/routes/killlife.ts`, `src/pages/CrazyLaneEditor.tsx`.
## Prochains lots recommandes
1. `T-AG-004` - brancher cette matrice dans les runbooks et TODOs companions sans casser les single-writer hotspots.
2. `T-UX-003` - exposer la matrice et les points d’insertion natifs dans les TUI operatoires.
3. `T-RE-204` - reprendre `zeroclaw-integrations` une fois la matrice agentique publiee.
4. `T-RE-209` - finaliser `yiacad-fusion` avec ownership strict `Arch-Mesh` / `CAD-Bridge`.
5. `T-OL-005` - requalifier le `model` explicite apres stabilisation complete du chemin par defaut.
## Delta 2026-03-20 - mapping spec/module T-UX-004
- `specs/yiacad_tux004_orchestration_spec.md` -> owner `DesignOps-UI` -> sous-agents `Sagan/Godel`, `Peirce/Locke`, `AgentMatrix lane`.
- module `kicad-ki/*` -> owner `Sagan/Godel lane` -> focus `command palette`, `review center`, `output contract hookup`.
- module `freecad-ki/src/Mod/YiACADWorkbench/*` -> owner `Peirce/Locke lane` -> focus `persistent inspector`, `review center`, `command palette`.
- module `tools/cad/yiacad_native_ops.py` -> owner `CAD IA runtime lane` -> focus `normalized outputs`, `context broker`, `artifact lineage`.
## Delta 2026-03-20 18:35 - canonical mapping T-UX-003 / T-UX-004
- `T-UX-003A` -> owner `CAD-UX / KiCad-Shell` -> write-set `kicad-ki/pcbnew/toolbars_pcb_editor.cpp`, `kicad-ki/eeschema/toolbars_sch_editor.cpp`
- `T-UX-003B` -> owner `CAD-UX / FreeCAD-Shell` -> write-set `freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- `T-UX-003C` -> owner `CAD-UX / KiCad-Native` -> write-set `kicad-ki/pcbnew/tools/board_editor_control.*`, `kicad-ki/eeschema/tools/sch_editor_control.*`
- `T-UX-003D` -> owner `CAD-UX / FreeCAD-Native` -> write-set `freecad-ki/src/Gui/MainWindow.cpp`
- `T-UX-004A` -> owner `CAD-UX / KiCad-Surface + FreeCAD-Surface` -> write-set `kicad-ki/scripting/plugins/yiacad_kicad_plugin/yiacad_action.py`, `freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- `T-UX-004B` -> owner `Doc-Research / Mermaid-Map + OSS-Watch` -> write-set `docs/YIACAD_*`, `docs/plans/20_*`, `specs/04_tasks.md`
- `Support UI/UX Ops` -> owner `SyncOps / TUI-Ops + Log-Guard` -> write-set `tools/cockpit/yiacad_uiux_tui.sh`, `artifacts/uiux_tui/*`
## Delta 2026-03-22 - canonical mapping intelligence web / plan 23
- `T-AI-320` -> owner `PM-Mesh / Plan-Orchestrator` -> write-set `specs/agentic_intelligence_integration_spec.md`, `docs/plans/22_*`, `tools/cockpit/intelligence_tui.sh`
- `T-AI-321` -> owner `Docs-Research / Runbook-Editor + Mermaid-Map + OSS-Watch` -> write-set `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md`, `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-22.md`, `docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-22.md`
- `T-AI-322` -> owner `Docs-Research / Plan-Recorder` -> write-set `docs/plans/12_plan_gestion_des_agents.md`, `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
- `T-AI-323` -> owner `Web-CAD-Platform / EDA-CI-Orchestrator + Realtime-Collab` -> write-set `web/lib/*`, `web/realtime/*`, `web/workers/*`, `tools/cockpit/intelligence_tui.sh`
- `T-AI-324` -> owner `Web-CAD-Platform / Project-Service` -> write-set `web/lib/project-store.ts`, `web/lib/graphql/*`, `web/app/api/*`
- `T-AI-325` -> owner `Web-CAD-Platform / Realtime-Collab` -> write-set `web/components/excalidraw-canvas.tsx`, `web/lib/realtime/*`, `web/components/project-shell.tsx`
- `T-AI-326` -> owner `Runtime-Companion / Review-Assist` -> write-set `web/lib/intelligence/*`, `docs/AI_WORKFLOWS.md`, `specs/mcp_agentics_target_backlog.md`
docs/AI_WORKFLOWS.md
+275 -15
View File
@@ -1,20 +1,280 @@
# AI workflows
# Workflows IA Kill_LIFE (2026-03-22)
## L3: Issue → PR
- Ajouter le label `ai:*` adapte a l'etape voulue (`ai:spec`, `ai:plan`, `ai:tasks`, `ai:impl`, `ai:qa`, `ai:docs`, `ai:hold`).
- Le workflow construit un prompt sécurisé + lance Codex + ouvre une PR.
Cette feuille de route pilote l’usage de l’IA en mode overlay: utile, traçable, non bloquante par défaut.
## Sequences de reference
## Flux principal
- workflow local : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
- workflow github : `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
```mermaid
flowchart TD
A[Demande humaine] --> B[PM / Plan]
B --> C[Spec + Plan]
C --> D[Spec/Plan validation + checks]
D --> E{Choix IA}
E -->|ai:spec| F[ai:spec]
E -->|ai:plan| G[ai:plan]
E -->|ai:tasks| H[ai:tasks]
E -->|ai:impl| I[ai:impl]
E -->|ai:qa| J[ai:qa]
E -->|ai:hold| K[ai:hold]
F --> L[Docs + Specs]
G --> L
H --> M[Backlog + priorités]
I --> N[Code / patches]
J --> O[Validation + tests + logs]
K --> P[Risque / décision humaine]
O --> Q[Evidence pack + preflight]
Q --> R[Close lot + mémoire]
```
Lecture :
- `local` couvre la validation avant dispatch, les checks repo-locaux et les preuves non distantes
- `github` couvre `workflow_dispatch`, statuts, checks CI, artifacts et evidence pack
## Flux dédié YiACAD
## Garde-fous
- input issue sanitizé (HTML comments removed)
- pas de sudo (drop-sudo)
- sandbox workspace-write
- tests post-Codex (firmware native)
```mermaid
flowchart TD
A[Demande lot YiACAD] --> B[yiacad-fusion:prepare]
B --> C[ai_native_forks.sh]
C --> D[yiacad-fusion:smoke]
D --> E{Smoke complet}
E -->|OK| F[yiacad-fusion:status]
E -->|KO| G[ai:hold + correction lot]
F --> H[logs/clean-logs]
H --> I[Update docs/plans/specs]
I --> J[weekly-summary]
J --> K[Evidence pack: artifacts/cad-fusion]
```
## Flux dédié YiACAD UI/UX
```mermaid
flowchart TD
A[Demande UI/UX Apple-native] --> B[Audit + research]
B --> C[Spec UI/UX + feature map]
C --> D[Agent matrix + owners]
D --> E[TUI UI/UX + logs]
E --> F[Native insertion points KiCad/FreeCAD]
F --> G{Montée shell compilé}
G -->|pas encore| H[hooks Python + runbooks]
G -->|oui| I[chrome natif + inspector + palette]
H --> J[plans/todos/readme]
I --> J
```
## Flux dedie YiACAD Git EDA + intelligence
```mermaid
flowchart TD
A[Demande produit web] --> B[Plan 23 + TODO 23]
B --> C[GraphQL project read model]
C --> D[Queue BullMQ]
D --> E[EDA worker]
E --> F[Artifacts + CI state]
C --> G[Yjs room state]
G --> H[Excalidraw / presence]
F --> I[Review center + PCB viewer]
I --> J{Overlay IA}
J -->|lecture seule| K[review hints / ops summary]
J -->|action outillee| L[MCP or service-first tool]
K --> M[intelligence_tui + plan 22/23]
L --> M
```
## Modes d’intégration IA (actuel)
| Mode | Usage | Contrôle |
| --- | --- | --- |
| `assisté` | génération de brouillon + proposition, sans écriture automatique | `owner_agent` requis, aucune écriture sans lot |
| `piloté` | exécution d’action avec pré-validation automatisée (spec/plan/tests) | logs + evidence + preflight |
| `manuel` | décision humaine requise (`ai:hold`) sur portée non maîtrisée | lot explicitement arrêté + justification |
## Etat de l'art 2026 retenu
- `MCP` reste le standard prioritaire pour la couche outils et discovery.
- `OpenAI Responses API` reste la bonne surface pour un overlay web `tools-first` si la lane review-assist s'ouvre, sans deplacer la source de verite hors Git.
- `Roo Code` est retenu comme reference de modes/personas outilles dans l'editeur.
- `OpenHands` est retenu comme reference de separation `SDK / CLI / GUI / cloud`.
- `LangGraph` reste la reference de workflows longs avec etat, reprise et human-in-the-loop.
- `OpenAI Agents SDK` reste une reference utile pour les patterns `tools + handoffs + sessions`, mais pas comme source de verite documentaire du projet.
## Delta officiel verifie le 2026-03-21
- `Model Context Protocol`: la release officielle du `2025-11-25` confirme MCP comme standard de fait pour connecter outils, donnees et applications aux LLM; la trajectoire 2025 a deja ajoute structured tool outputs, OAuth-based authorization et elicitation. Source: [One Year of MCP: November 2025 Spec Release](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/) et [Update on the Next MCP Protocol Release](https://blog.modelcontextprotocol.io/posts/2025-09-26-mcp-next-version-update/).
- `OpenAI Tools / Responses API`: au `2026-03-22`, la doc officielle outille clairement une approche `tools-first`, avec `MCP and Connectors`, `WebSocket mode`, `background mode` et `tracing/evals` dans la meme famille de docs. Decision projet: si une aide IA web s'ouvre, elle restera un overlay de review et d'ops, jamais une source de verite en concurrence avec Git/Yjs/workers. Source: [Using tools](https://developers.openai.com/api/docs/guides/tools).
- `VS Code AI extensibility`: l'API officielle de tools positionne explicitement les `extension tools`, les `built-in tools` et les `MCP tools` comme briques de l'agent mode. Decision projet: garder les extensions `studio/mesh/operator` legères et reutiliser MCP quand l'outil doit rester cross-environment. Source: [Language Model Tool API](https://code.visualstudio.com/api/extension-guides/tools) et [Chat tutorial](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial).
- `OpenAI Agents SDK`: les patterns officiellement solides pour ce repo sont `handoffs`, `tools`, `mcp_servers` et `tracing`, donc des overlays de coordination et d'observabilite, pas une source de verite documentaire. Source: [Agents](https://openai.github.io/openai-agents-python/agents/), [Handoffs](https://openai.github.io/openai-agents-js/guides/handoffs/), [Tracing](https://openai.github.io/openai-agents-js/guides/tracing/).
- `LangGraph`: reste la meilleure reference officielle pour les workflows longs avec durable execution, checkpoints et human-in-the-loop. Decision projet: deferer l'adoption au-dessus des contrats `summary-short/v1` et `runtime-mcp-ia-gateway/v1`, pas en dessous. Source: [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview).
## Surfaces IA et gouvernance
| Surface | Mode | Règle de contrôle |
| --- | --- | --- |
| `specs/` | piloté | `python3 tools/validate_specs.py --strict --require-mirror-sync` |
| Documentation | assisté | revue humaine + préflight README coherence |
| QA | piloté | preuves de tests + traces d’exécution |
| MCP/Runtime | piloté | `ai:*` labels, denylist, preuve de lot |
| Firmware/Hardware | assisté-piloté | pas d’écriture sans lot + validation |
| CAD / KiCad / FreeCAD | piloté | `tools/cad/yiacad_fusion_lot.sh` + preflight + evidence |
| UI/UX Apple-native | piloté | `tools/cockpit/yiacad_uiux_tui.sh` + `tools/cockpit/agent_matrix_tui.sh` + preuves docs |
| Web Git EDA / `web/` | piloté | `docs/plans/23_*`, Git source of truth, Yjs transport, workers BullMQ, review-assist en lecture seule |
## Politique canonique 2026-03-21
### Root vs miroir
- `Kill_LIFE/specs/` reste la source de vérité documentaire et contractuelle.
- `ai-agentic-embedded-base/specs/` reste un miroir exporté piloté par `bash tools/specs/sync_spec_mirror.sh all --yes`.
- Les surfaces `docs/`, `tools/`, `artifacts/` et `firmware/` ne sont pas mirror-first: on les maintient dans `Kill_LIFE`, puis on exporte seulement si un lot le demande explicitement.
- La validation de fermeture d'un lot spec-first combine `bash tools/specs/sync_spec_mirror.sh all --yes` et `python3 tools/validate_specs.py --strict --require-mirror-sync`.
### Firmware canonique actuel
- Le chemin executable canonique pour la phase active est `firmware/platformio.ini` + `firmware/src/main.cpp`.
- `firmware/src/voice_controller.cpp` et `firmware/include/voice_controller.h` restent une stack voice en pre-integration: presentes dans le repo, mais pas branchees au `main.cpp` ni a une lane release testee.
- `ai-agentic-embedded-base/firmware/` reste un seed minimal compagnon; il ne doit pas etre utilise comme verite runtime ou release path.
- La gateway `runtime_ai_gateway.sh` publie maintenant une surface auxiliaire `firmware_cad` plus un artefact `summary-short/v1` compagnon (`artifacts/cockpit/runtime_ai_gateway/firmware_cad_summary_short_latest.json`) a partir du `firmware/` racine et de `artifacts/yiacad_backend_proof/latest.json`.
- Le statut `voice` reste indirect tant que `voice_controller.*` n'est pas branche au boot avec une preuve build/test/release explicite.
## Contrats de gouvernance intelligence
Deux contrats minimaux servent maintenant de base commune pour la gouvernance intelligence:
- `summary-short/v1`: `specs/contracts/summary_short.schema.json`
- `runtime-mcp-ia-gateway/v1`: `specs/contracts/runtime_mcp_ia_gateway.schema.json`
Le premier sert a publier une synthese courte stable avec:
- `contract_version`
- `generated_at`
- `component`
- `owner_repo`
- `owner_agent`
- `owner_subagent`
- `write_set`
- `status`
- `summary_short`
- `evidence`
Le second sert a publier une sante agregee pour:
- `runtime`
- `mcp`
- `ia`
avec un `status` global, un `summary_short` global, une `evidence` exploitable par automation, plus:
- `contract_version`
- `generated_at`
- `component`
`cockpit-v1` reste l'enveloppe de transport des TUIs et des artefacts cockpit.
Le "contrat lot" n'est pas un troisieme schema canonique: c'est un overlay derive de `cockpit-v1` et/ou `summary-short/v1` selon la surface.
## Contrat lot (run-time)
Le contrat de lot canonique doit porter au minimum:
- `owner_repo`
- `owner_agent`
- `owner_subagent`
- `write_set`
- `status`
- `evidence`
Champs recommandés en plus:
- `lot_id`
- `mesh_status` pour le signal runtime `ready|degraded|blocked`
- `degraded_reasons`
- `next_steps`
Pour une lane de gouvernance intelligence, l'evidence recommandee devient:
- un artefact `summary-short/v1` pour la lecture courte
- un artefact `runtime-mcp-ia-gateway/v1` pour la sante `runtime/mcp/ia`
Exemple:
- `lot_id: lc-019`, `owner_repo: Kill_LIFE`, `owner_agent: PM-Mesh`, `owner_subagent: Plan-Orchestrator`, `write_set: docs/AI_WORKFLOWS.md,docs/REFACTOR_MANIFEST_2026-03-20.md`, `status: degraded`, `evidence: artifacts/cockpit/intelligence_program/latest.json`.
- Les lots `autonomous_next_lots` exposent ce contrat en JSON lorsqu'ils sont exécutés avec `--json`.
## Références officielles 2026 vérifiées
- [VS Code AI extensibility](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial)
- [Model Context Protocol intro](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Model Context Protocol registry](https://registry.modelcontextprotocol.io/)
- [OpenAI tools guide](https://developers.openai.com/api/docs/guides/tools)
- [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/)
- [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview)
## Carte opérationnelle IA-native CAD
```mermaid
flowchart LR
RepoSpecs[specs/] --> CADPlan[docs/CAD_AI_NATIVE_FORK_STRATEGY.md]
CADPlan --> Fork[kicad + freecad branches]
Fork --> Launch[tools/hw/* + MCP launchers]
Launch --> Audit[tools/cockpit/mesh_sync_preflight.sh]
Audit --> Logs[artifacts/refonte_tui/*.log]
Logs --> Revue[docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md]
Revue --> CadTask[docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md]
CadTask --> LotSync[tools/cockpit/lot_chain.sh]
LotSync --> Summary[tools/cockpit/render_weekly_refonte_summary.sh]
```
## Carte tri-repo et exécution
```mermaid
flowchart TD
Mesh[contracts tri-repo] --> Preflight[mesh_sync_preflight.json]
Preflight --> Status{mesh_status}
Status -->|ready| Autonomous[autonomous next lots]
Status -->|degraded| Controlled[run contrôlé + lots]
Status -->|blocked| Hold[ai:hold + opérateur]
Controlled --> LogsOps[log_ops + analyse]
Autonomous --> LogsOps
LogsOps --> Question[artifacts/cockpit/next_question.md]
```
## Commandes de pilotage recommandées
- Lire et valider la cohérence:
- `bash tools/cockpit/refonte_tui.sh --action log-ops`
- `bash tools/doc/readme_repo_coherence.sh all --yes`
- `python3 tools/validate_specs.py --strict --require-mirror-sync`
- Gestion logs (lecture/analyse/purge contrôlée):
- `bash tools/cockpit/refonte_tui.sh --action logs`
- `bash tools/cockpit/refonte_tui.sh --action clean-logs --days 14 --yes-auto`
- `bash tools/cockpit/refonte_tui.sh --action clean-logs --days 7 --yes-auto`
- Lot YiACAD:
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:prepare`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:smoke`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:status`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:logs`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:clean-logs --days 7 --yes`
- Lot YiACAD UI/UX:
- `bash tools/cockpit/yiacad_uiux_tui.sh --action status`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action insertion-points`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action agent-matrix`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action logs-summary`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action logs-list`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action logs-latest`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action purge-logs --days 14 --yes`
- Synthèse opératoire:
- `bash tools/cockpit/refonte_tui.sh --action weekly-summary`
- `bash tools/cockpit/render_weekly_refonte_summary.sh`
- Gouvernance intelligence:
- `bash tools/cockpit/intelligence_tui.sh --action status --json`
- `bash tools/cockpit/intelligence_tui.sh --action next-actions`
- `bash tools/cockpit/intelligence_tui.sh --action memory --json`
- `bash tools/cockpit/intelligence_tui.sh --action scorecard --json`
- `bash tools/cockpit/intelligence_tui.sh --action comparison --json`
- `bash tools/cockpit/intelligence_tui.sh --action recommendations --json`
- `bash tools/cockpit/refonte_tui.sh --action intelligence`
- `bash tools/cockpit/refonte_tui.sh --action log-ops`
- `bash tools/cockpit/log_ops.sh --action purge --retention-days 7 --apply`
- Lot-chain:
- `bash tools/run_autonomous_next_lots.sh status`
- `bash tools/run_autonomous_next_lots.sh run`
- `bash tools/autonomous_next_lots.py json`
- Raccourcis santé:
- `bash tools/cockpit/refonte_tui.sh --action status`
- `bash tools/cockpit/refonte_tui.sh --action mesh-preflight`
- `bash tools/cockpit/refonte_tui.sh --action mcp-check`
docs/ARTIFACT_WMS_INDEX_2026-03-22.md
+83
View File
@@ -0,0 +1,83 @@
# Artifact WMS Index
Date: 2026-03-22
Status: baseline WMS index
Scope: index `artifacts/` by lot, consumer layer, owner agent, and purpose
## 1. Objective
The `WMS` layer in `Kill_LIFE` already stores many useful artifacts, but retrieval is still uneven.
This index closes the minimum gap:
- map `artifact -> lot -> consumer layer -> owner agent`
- expose one TUI surface for summary and retrieval
- make unknown artifacts visible instead of silently ignored
## 2. Canonical files
Structured rules:
- [artifact_wms_index_rules.json](/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs/contracts/artifact_wms_index_rules.json)
Operator TUI:
- [artifact_wms_index_tui.sh](/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/artifact_wms_index_tui.sh)
## 3. Supported views
- `summary`
- `entries`
- `unknown`
Examples:
```bash
bash tools/cockpit/artifact_wms_index_tui.sh --action summary
bash tools/cockpit/artifact_wms_index_tui.sh --action entries --json
bash tools/cockpit/artifact_wms_index_tui.sh --action unknown --json
```
## 4. Reading
The index is intentionally pragmatic:
- it scans `latest*` artifacts under `artifacts/`
- it applies explicit keyword-based rules from the contract
- unmatched artifacts are exposed as `unknown`
This is enough to close the immediate `WMS` gap without introducing a heavy metadata service.
## 5. Current classification model
Examples of classified artifact families:
- `product_contract_*` -> `MES`
- `kill_life_memory` -> `MES`
- `daily_operator_summary` -> `MES`
- `mascarade_incident_*` -> `WMS`
- `mascarade_watch_*` -> `WMS`
- `mascarade_runtime_health` -> `DCS`
- `dataset_*` -> `WMS`
- `repo_state` / `specs` -> `PLM`
- `operator_lane` -> `MES`
## 6. Why this closes the layer gap
Before this index:
- artifacts existed
- latest outputs existed
- handoff files existed
- but there was no direct machine-readable map from artifact to lot family and consumer
After this index:
- `WMS` has a contract
- `WMS` has a TUI surface
- `unknown` artifacts become visible technical debt instead of silent drift
## 7. Next step
Best next step:
- branch this index into the main cockpit entrypoint
- then reduce `unknown` artifact groups until the index becomes the practical source of truth for `WMS`
docs/CAD_AI_NATIVE_FORK_STRATEGY.md
+204
View File
@@ -0,0 +1,204 @@
# Fork IA-native KiCad + FreeCAD (YiACAD) pour Kill_LIFE
Objectif: disposer de forks dédiés pour la couche technique `AI-native` de Kill_LIFE
(automations MCP, scripts de conversion, audits, benchmarks) sans casser la chaîne principale.
Le lot associé est nommé **YiACAD** et pilote une fusion opérationnelle **KiCad + FreeCAD**
(avec OpenSCAD en couverture 3D) dans un mode host-first piloté par lot.
## 1) Principe de production
1. Ne pas réinventer la stack existante:
- conserver `tools/hw/cad_stack.sh`, `tools/hw/run_kicad_mcp.sh` et `tools/run_freecad_mcp.sh`.
2. Maintenir les forks locaux de référence:
- `KiCad/ KiCad`
- `FreeCAD/FreeCAD`
3. Travailler des branches IA-native par repo:
- `kill-life-ai-native`
4. Garder un manifeste de provenance et de remotes stable:
- fork `origin`
- source `upstream`
## 2) Script d'amorçage (prêt à exécuter)
Le script de base ajouté:
- `tools/cad/ai_native_forks.sh`
Flux type:
1. Préparer l’infra locale:
```bash
mkdir -p .runtime-home/cad-ai-native-forks
```
2. Générer une base locale sans créer de fork GitHub:
```bash
bash tools/cad/ai_native_forks.sh --dry-run --base-dir .runtime-home/cad-ai-native-forks
```
3. Créer les forks GitHub (si besoin), puis cloner:
```bash
gh auth login
bash tools/cad/ai_native_forks.sh \
--create-forks \
--base-dir .runtime-home/cad-ai-native-forks \
--owner <ton-org-github> \
--branch kill-life-ai-native
```
4. Vérifier le manifeste:
```bash
cat .runtime-home/cad-ai-native-forks/manifest.md
```
## 3) Lot YiACAD (pilotage de fusion CAD)
Le lot `yiacad-fusion` regroupe l'amorçage + smoke CAD + preuves:
- préparation des forks (`prepare`) via `tools/cad/ai_native_forks.sh`
- smoke de santé CAD (`smoke`) via:
- `tools/hw/cad_stack.sh doctor-mcp`
- `tools/hw/run_kicad_mcp.sh --doctor`
- `tools/hw/kicad_host_mcp_smoke.py --json --quick`
- `tools/freecad_mcp_smoke.py --json --quick`
- `tools/openscad_mcp_smoke.py --json --quick`
- `tools/run_freecad_mcp.sh --doctor`
- `tools/run_openscad_mcp.sh --doctor`
- statut (`status`) et logs (`logs`) dans `artifacts/cad-fusion`
- purge contrôlée (`clean-logs`) avec rétention définie.
Entrées disponibles:
- `bash tools/cad/yiacad_fusion_lot.sh --action prepare`
- `bash tools/cad/yiacad_fusion_lot.sh --action smoke`
- `bash tools/cad/yiacad_fusion_lot.sh --action status`
- `bash tools/cad/yiacad_fusion_lot.sh --action logs`
- `bash tools/cad/yiacad_fusion_lot.sh --action clean-logs --days 7 --yes`
- via cockpit: `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:prepare`
- via cockpit: `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:smoke`
Lancement standard:
```bash
bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:prepare
bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:smoke
```
## 4) Intégration Kill_LIFE
- `tools/cad/ai_native_forks.sh` orchestre déjà:
- le clone local des dépôts,
- la création éventuelle de branches `kill-life-ai-native`,
- la normalisation des remotes (`origin`/`upstream`).
- Le flux de refonte attend que chaque lot touchant KiCad/FreeCAD fournisse:
- un `lot_id`,
- un `owner_agent` explicite,
- un `write_set` restreint,
- une preuve `log_ops`,
- et une validation `mesh_status` (de `mesh_sync_preflight.sh`).
- Les preuves YiACAD sont archivées dans:
- `artifacts/cad-fusion/yiacad-fusion-last.log`
- `artifacts/cad-fusion/yiacad-fusion-last-status.md`
## 5) Structure actuelle (2026-03-20 11:20)
- Base locale: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/.runtime-home/cad-ai-native-forks/`
- Répertoires détectés:
- `kicad-ki` (branche `kill-life-ai-native` préparée localement)
- `freecad-ki` (branche `kill-life-ai-native` préparée localement)
- Remotes:
- `origin` (fork GitHub cible)
- `upstream` (remote principal)
- Manifeste actif:
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/.runtime-home/cad-ai-native-forks/manifest.md`
- Artefacts YiACAD:
- `artifacts/cad-fusion/`
## 6) Prochaine phase opérationnelle
- `--create-forks` non encore exécuté côté GitHub (forks distants non publiés).
- Après création des forks distants:
- pousser la branche `kill-life-ai-native`,
- déclarer les remotes `origin`/`upstream`,
- publier la preuve de CI dans:
- `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`
- `CHANGELOG_AI_NATIVE.md` (par repo fork)
- compléter la preuve YiACAD (prepare + smoke + status + purge contrôlée).
## 6bis) Dernière exécution opératoire validée (2026-03-21 13:31 CET)
- `prepare`: `ok`
- manifeste présent
- `kicad-ki` sur `kill-life-ai-native` (`eec5b07179`)
- `freecad-ki` sur `kill-life-ai-native` (`5ea732ef3c`)
- `status`: `ok`
- snapshot canonique mis à jour dans `artifacts/cad-fusion/yiacad-fusion-last-status.md`
- `logs`: `ok`
- l’inventaire `artifacts/cad-fusion/*` reste lisible via `tools/cad/yiacad_fusion_lot.sh --action logs`
- `clean-logs --days 14`: `ok`
- aucun candidat à purger sur cette passe
- `smoke`: `blocked`
- `CAD stack doctor`: `ok`
- `KiCad MCP host doctor`: `ok`
- `KiCad MCP host smoke`: `blocked`
- `FreeCAD MCP smoke`: `ready`
- `OpenSCAD MCP smoke`: `ready`
- blocage observé:
- la lane `mascarade-main` ne matérialise pas l’entrypoint hôte attendu: `finetune/kicad_mcp_server/dist/index.js`
- le doctor KiCad recadre désormais `REQUESTED_RUNTIME=auto` vers `SELECTED_RUNTIME=container`
- la priorité immédiate est soit de matérialiser cet entrypoint, soit de conserver explicitement le fallback conteneur comme état supporté
- preuves:
- `artifacts/cad-fusion/yiacad-fusion-last.log`
- `artifacts/cad-fusion/yiacad-fusion-last-status.md`
- `artifacts/refonte_tui/refonte_tui_20260321_133030.log`
- `artifacts/refonte_tui/refonte_tui_20260321_133042.log`
## 7) Gouvernance de livraison
- Point d'entrée IA-native:
- lier toute évolution KiCad/FreeCAD aux lots `T-LOT-*` et aux tâches mesh tri-repo.
- Règles minimales:
- aucune écriture directe sur `main` sans lot validé,
- passer par le cockpit TUI (`tools/cockpit/refonte_tui.sh`) pour préflight/log + evidence,
- valider les artefacts CAD avant export (ERC/DRC/BOM/netlist/export).
- Alignement externe:
- maintenir la veille OSS similaire (`docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`) en revue périodique.
- Carte de conformité YiACAD:
- chaque exécution du lot doit produire un statut, un log et le fichier `status` mis à jour.
## 8) Carte opérationnelle IA-native CAD (2026-03-20)
```mermaid
flowchart TD
Docs[docs/CAD_AI_NATIVE_FORK_STRATEGY.md] --> ForkState[tools/cad/ai_native_forks.sh]
ForkState --> Branches[branches kill-life-ai-native]
Branches --> MCPOverlay[tools/hw/run_kicad_mcp.sh / tools/run_freecad_mcp.sh]
MCPOverlay --> HostFirst[tools/hw/cad_stack.sh]
HostFirst --> Preflight[tools/cockpit/mesh_sync_preflight.sh]
Preflight --> LotRouting[tools/cockpit/lot_chain.sh]
LotRouting --> Evidence[artifacts/refonte_tui/*.log + artifacts/cad-fusion/*.log]
Evidence --> RepoPlan[docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md]
RepoPlan --> ReadmeGate[tools/doc/readme_repo_coherence.sh]
RepoPlan --> Revue[docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md]
```
## 9) Rappels de conformité
- `constraints.yaml` reste source de vérité pour les choix d’outils.
- Les gates hardware (`ERC/DRC/netlist/BOM`) restent obligatoires pour les artefacts exportés vers `Kill_LIFE`.
- Aucune modification de source upstream n’est poussée sans branche dédiée et revue.
## 10) Delta 2026-03-21 - etat reel `yiacad-fusion`
- le write-set `Kill_LIFE` du lot est maintenant proprement cadre:
- `tools/cad/yiacad_fusion_lot.sh`
- `tools/cockpit/refonte_tui.sh`
- `tools/cockpit/render_weekly_refonte_summary.sh`
- ce document de strategie
- l'hygiene locale est alignee:
- `refonte_tui.sh` propage maintenant `--days` vers `yiacad-fusion:clean-logs`
- la synthese hebdomadaire distingue explicitement le blocage externe du repo local
- le blocage dur restant reste externe a `Kill_LIFE`:
- `mascarade-main/finetune/kicad_mcp_server/dist/index.js` n'est pas materialise
- tant que cet entrypoint hote manque, `KiCad MCP host smoke` reste `blocked`
- consequence operatoire:
- `yiacad-fusion` peut etre clos comme lot `implémenté/documenté`, mais ne doit pas etre promu comme lane `ready` sans soit materialisation de cet entrypoint, soit decision explicite d'accepter le fallback conteneur comme etat supporte.
docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md
+52
View File
@@ -0,0 +1,52 @@
# YiACAD Native GUI Runbook
Date: `2026-03-20`
## Objectif
Ajouter une premiere couche GUI + utilitaires IA directement dans KiCad et FreeCAD, sans modifier les upstreams pour l'instant.
## Composants ajoutes
- Pont partage: `tools/cad/yiacad_ai_bridge.py`
- Installateur local: `tools/cad/install_yiacad_native_gui.sh`
- Plugin KiCad: `tools/cad/integrations/kicad/yiacad_kicad_plugin/`
- Workbench FreeCAD: `tools/cad/integrations/freecad/YiACADWorkbench/`
## Fonctions exposees
- queue d'une requete IA locale depuis KiCad ou FreeCAD
- lecture du dernier statut YiACAD
- ouverture rapide des artefacts locaux
- routage des demandes dans `artifacts/cad-ai-requests/`
## Installation locale
```bash
bash tools/cad/install_yiacad_native_gui.sh install
bash tools/cad/install_yiacad_native_gui.sh status
```
Par defaut sur macOS:
- KiCad: `~/Library/Application Support/kicad/scripting/plugins`
- FreeCAD: `~/Library/Application Support/FreeCAD/Mod`
## Affectation agents / sous-agents
- `CAD-Fusion`: pilote de la surface GUI IA-native
- `CAD-Bridge`: integrateur plugin/workbench et bridge local
- `CAD-Smoke`: qualifie le chemin de requete et le statut YiACAD
- skill principal: `bash-cli-tui`
## Etat courant
- KiCad: plugin ActionPlugin chargeable, compatible avec le menu `Tools -> External Plugins`
- FreeCAD: workbench Python chargeable avec toolbar/menu `YiACAD AI`
- Les requetes sont versionnees localement dans `artifacts/cad-ai-requests`
## Suite recommandee
1. Brancher les actions KiCad sur l'IPC API lorsque la couche upstream YiACAD passera au fork natif.
2. Ajouter un panneau de retour IA avec lecture des reponses, pas seulement la mise en queue.
3. Connecter les requetes a des utilitaires concrets: ERC/DRC, BOM review, sync ECAD/MCAD, generation STEP.
docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md
+47
View File
@@ -0,0 +1,47 @@
# CAD AI Native Hooks - 2026-03-20
## Objectif
Basculer les surfaces utilisateur KiCad et FreeCAD de YiACAD vers des hooks directs dans les forks natifs, sans passer par le bridge générique.
## Surfaces natives
- KiCad: `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin`
- FreeCAD: `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench`
## Utilitaires concrets
- `python3 tools/cad/yiacad_native_ops.py kicad-erc-drc --source-path <path>`
- `python3 tools/cad/yiacad_native_ops.py bom-review --source-path <path>`
- `python3 tools/cad/yiacad_native_ops.py ecad-mcad-sync --source-path <path>`
- `python3 tools/cad/yiacad_native_ops.py status`
## Artefacts
- Dossier: `artifacts/cad-ai-native/`
- Chaque exécution génère `summary.md`, `result.json` et les logs stdout/stderr des commandes CAD invoquées.
## Bascule utilisateur
La reliaison des surfaces utilisateur vers les forks natifs se fait avec:
```bash
bash tools/cad/switch_yiacad_surfaces_to_native_forks.sh
```
## Notes de câblage
- KiCad déclenche directement `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`, `Status`, `Artifacts`.
- FreeCAD expose les mêmes utilitaires depuis un workbench dédié, en réutilisant le document actif pour retrouver les fichiers KiCad voisins.
- `ECAD/MCAD Sync` exporte les artefacts STEP côté KiCad et tente l’export STEP côté FreeCAD quand un runtime headless est disponible.
## Delta 2026-03-20 - extension KiCad compiled shells
- `KiCad Manager`, `pcbnew` et `eeschema` disposent maintenant chacun d'une entrée native `YiACAD Status`.
- Les premières interactions restent volontairement modestes: affichage de statut via le bridge local, sans divergence backend supplémentaire.
- Ce palier valide l'occupation du chrome compilé KiCad avant la montée vers les workflows IA complets `ERC/DRC`, `BOM review` et `ECAD/MCAD sync`.
## Delta 2026-03-20 - direct native runner
- La première génération de hooks directs YiACAD est désormais en place.
- KiCad et FreeCAD ne s'appuient plus sur `yiacad_ai_bridge.py` pour les surfaces natives principales.
- Le socle d'actions exposé depuis les UIs est homogène entre ECAD et MCAD: `Status`, `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`.
- La prochaine étape de refonte porte sur l'expérience d'orchestration et de lecture des résultats, pas sur la simple disponibilité des commandes.
docs/FAB_PACKAGE_CONTRACT_2026-03-22.md
+58
View File
@@ -0,0 +1,58 @@
# Fab package contract (2026-03-22)
## Objectif
Donner a `Kill_LIFE` un contrat local unique pour la preparation fabrication PCB, avant tout handoff `Quilter`, `PCB Designer AI` ou `JLCPCB`.
Le contrat couvre le minimum requis:
- `BOM`
- `CPL`
- `Gerber`
- `drill`
- `DRC`
- `review artifacts`
- `provenance`
Le but n'est pas de remplacer `YiACAD`, `schops` ou `hw_check`.
Le but est de les agreger dans un package unique et traçable.
## Principe
- `schops` reste la source deterministe pour `ERC`, `netlist`, `BOM`
- `YiACAD` reste la source de review locale pour `ERC/DRC` et `bom-review`
- le `fab package` est la couche d'orchestration au-dessus
- toute lane externe doit redescendre vers ce contrat
## Flux retenu
```mermaid
flowchart LR
SCH["schematic"] --> SCHOPS["schops erc/netlist/bom"]
SCH --> YI["YiACAD bom-review + kicad-erc-drc"]
BRD["board"] --> GERB["Gerber / drill export"]
SCHOPS --> PKG["fab package"]
YI --> PKG
GERB --> PKG
PKG --> ART["artifacts/cockpit/fab_package"]
PKG --> EXT["Quilter / PCB Designer AI / JLCPCB handoff"]
```
## Regles d'acceptation
Un package est:
- `ready` si les gates `erc_ok`, `drc_ok`, `bom_review_ok`, `artifacts_complete` sont vrais
- `degraded` si la chaine a produit des artefacts partiels mais pas un package fabrication complet
- `blocked` si les sources d'entree sont absentes ou inutilisables
## Constat 2026-03-22
- le repo courant ne fournit pas encore d'export `CPL` local canonique
- le repo courant ne fournit pas encore de package fabrication unique
- les assets Hypnoled references dans le TODO 25 ne sont pas presents dans ce checkout
Conclusion:
- le contrat `fab package` est maintenant cadre
- le premier objectif d'execution est de produire une chaine locale honnete `ready|degraded|blocked`
- la parite complete `JLCPCB assembly-ready` reste un lot suivant
docs/FULL_OPERATOR_LANE_2026-03-20.md
+72
View File
@@ -0,0 +1,72 @@
# Full operator lane - 2026-03-20
## Scope
This lot closes the operator path `crazy_life -> Kill_LIFE -> mascarade` while staying multi-contributor safe.
## Runtime contract
- Workflow source of truth: `workflows/embedded-operator-live.json`
- Gateway execution surface: `/api/killlife/workflows/:id/run`
- Live provider bridge:
- container-safe runner: `tools/ops/operator_live_provider_smoke.js`
- parity/debug runner: `tools/ops/operator_live_provider_smoke.py`
- Mascarade endpoints:
- `/api/agents/providers`
- `/v1/chat/completions` on `core`
- Evidence contract: `specs/contracts/operator_lane_evidence.schema.json`
## Mermaid
```mermaid
flowchart LR
CLUI[crazy_life UI / Crazy Lane] --> CLAPI[crazy_life API]
CLAPI --> KLRUN[Kill_LIFE workflow run]
KLRUN --> KLSCRIPT[operator_live_provider_smoke.js]
KLSCRIPT --> MAPISUM[/mascarade api/agents/providers]
KLSCRIPT --> MCHAT[/mascarade core /v1/chat/completions]
MCHAT --> PROVIDER[LLM provider]
KLSCRIPT --> EVIDENCE[artifacts/operator_lane/live_provider_result.json]
EVIDENCE --> CLAPI
CLUI --> OPS[OpsHub / Infrastructure]
OPS --> MMON[mascarade runtime posture]
```
## Acceptance map
| Surface | Path | Expected outcome |
| --- | --- | --- |
| Dry-run | `mode=local`, `dry_run=true` | `run_id` created and evidence refs previewed |
| Live provider | `mode=local`, `dry_run=false` | provider selected or explicit `degraded/blocked` result persisted |
| Operator evidence | `artifacts/operator_lane/live_provider_result.json` | JSON readable from the cockpit |
| TUI runbook | `bash tools/cockpit/full_operator_lane.sh <cmd>` | timestamped log + JSON summary |
## Validated state on `clems`
- Dry-run proof:
- command: `bash tools/cockpit/full_operator_lane.sh dry-run --json`
- result: `success`
- run id: `4a9adf87-1695-4321-86a2-e066a0988533`
- Live proof:
- command: `bash tools/cockpit/full_operator_lane.sh live --json`
- result: `success`
- run id: `5ef4909f-8747-4634-a6a6-d131692787b0`
- provider: `claude`
- model: `claude-sonnet-4-6`
## Compatibility notes from the validated run
- `mascarade-api` did not have `python3`; the live bridge had to move to Node for container execution.
- The current runtime rejected `system` as a chat message role and only succeeded once the prompt was hoisted to the top-level `system` field.
- The most stable path in this lot was to let the runtime choose its own default model; explicit `openai:*` forcing was not reproducibly stable.
- The operator runners are now aligned with that rule: `model` is only sent on explicit operator override.
- The proof note and official source links are captured in `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`.
## TUI
- `bash tools/cockpit/full_operator_lane.sh status`
- `bash tools/cockpit/full_operator_lane.sh dry-run`
- `bash tools/cockpit/full_operator_lane.sh live`
- `bash tools/cockpit/full_operator_lane.sh all`
- `bash tools/cockpit/full_operator_lane.sh purge`
- `bash tools/cockpit/full_operator_lane_sync.sh --json`
docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md
+192
View File
@@ -0,0 +1,192 @@
# Audit de consolidation Kill_LIFE + Extensions
Date: `2026-03-21`
Périmètre actif:
- `Kill_LIFE`
- `ai-agentic-embedded-base`
- `kill-life-studio`
- `kill-life-mesh`
- `kill-life-operator`
Surfaces adjacentes documentées, hors refonte de premier rang:
- `mascarade`
- `crazy_life`
- `zeroclaw`
- `openclaw`
## Résumé exécutif
Kill_LIFE possède déjà un socle rare et solide: une gouvernance spec-first explicite, un cockpit shell/TUI structuré, des contrats JSON/MCP qui commencent à converger, et une vraie culture de preuve. En revanche, le centre de gravité du projet s'est déplacé plus vite que sa documentation: le repo raconte encore parfois un "template embarqué générique" alors qu'il sert désormais de control plane public pour un programme multi-repo, multi-lanes et multi-extensions.
La décision de consolidation du `2026-03-21` est la suivante:
- `Kill_LIFE` devient le control plane public, documentaire et opératoire
- `kill-life-studio` devient le produit pilote pour l'expérience auteur et les artefacts produit
- `kill-life-mesh` hérite ensuite du socle robuste pour l'orchestration multi-repo
- `kill-life-operator` hérite ensuite du même socle pour l'exécution, les checks et les preuves
## Sources de vérité canoniques
| Surface | Source canonique | Rôle |
| --- | --- | --- |
| Produit / programme | `README.md` | vision, périmètre, décisions de consolidation |
| Navigation opérateur | `docs/index.md` | table de routage docs et runbooks |
| Cockpit / TUI | `tools/cockpit/README.md` | commandes, contrats `cockpit-v1`, routines |
| Chaîne spec-first | `specs/README.md` | séquence canonique et contrat de lot |
| Audit consolidé | ce document | diagnostic, priorités, matrice IA |
| Veille OSS | `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md` | benchmark externe et décisions d'adoption |
## Diagramme de consolidation
```mermaid
flowchart LR
KL["Kill_LIFE<br/>control plane public"] --> DOCS["README + docs/index + cockpit/README + specs/README"]
KL --> COCKPIT["Cockpit shell/TUI<br/>preuves + contrats JSON"]
KL --> SPECS["Chaîne spec-first<br/>00 -> 04"]
SPECS --> STUDIO["kill-life-studio<br/>produit pilote"]
STUDIO --> MESH["kill-life-mesh<br/>contrats + handoffs"]
STUDIO --> OPS["kill-life-operator<br/>checks + evidence"]
KL -. interfaces documentées .-> MASQ["mascarade / crazy_life"]
KL -. runtimes adjacents .-> EXT["zeroclaw / openclaw"]
```
## Points forts
- Chaîne spec-first déjà installée, lisible et outillée.
- Cockpit shell/TUI riche avec sorties JSON, logs, preuves et modes dégradés.
- Une surface `intelligence_tui` relie maintenant audit, spec, plan, TODO, research, owners, memoire et prochaines actions.
- Contrats MCP et runtime déjà présents, avec une vraie logique `ready | degraded | blocked`.
- Tests Python repo-locaux déjà en place pour les surfaces critiques de validation.
- Matrice agents/sous-agents déjà amorcée, donc gouvernance extensible sans repartir de zéro.
- Positionnement YiACAD, CAD IA-native et bridge opérateur déjà documentés avec un niveau de détail rare.
## Points faibles
- Documentation trop éclatée: plusieurs "pages d'entrée" racontent des versions différentes du projet.
- README racine encore partiellement rédigé comme un template générique et non comme un control plane tri-repo.
- Dépendances locales/SSH/Docker nombreuses, donc testabilité et onboarding encore fragiles.
- Gros scripts shell/TUI encore inégalement testés malgré la convergence documentaire vers `cockpit-v1`.
- Les trois extensions VS Code existaient surtout comme variations de branding; leur promesse produit restait insuffisamment spécialisée.
## Opportunités d'amélioration
- Utiliser `kill-life-studio` comme surface auteur unique: brief, spec, decisions, acceptance criteria, plan.
- Réutiliser le même socle d'état dans Mesh et Operator pour éviter trois implémentations divergentes.
- Pousser les contrats JSON cockpit jusqu'aux surfaces qui publient encore du texte ad hoc.
- Réduire le nombre de documents concurrents en privilégiant des pages d'entrée courtes et des documents de référence denses.
- Transformer la veille OSS en décisions d'adoption explicites, pas en catalogue parallèle.
- Brancher la memoire `artifacts/cockpit/intelligence_program/latest.*` vers les automatisations et les extensions terminales.
## Risques et garde-fous
| Risque | Impact | Garde-fou retenu |
| --- | --- | --- |
| Inflation documentaire | perte de lisibilité | consolider avant de créer, et garder un seul point d'entrée par surface |
| Divergence entre extensions | dette produit + support | `kill-life-studio` pilote, puis propagation du socle validé |
| Scripts shell difficiles à fiabiliser | régressions opératoires | contrats JSON communs + tests de contrat ciblés |
| Dépendances externes instables | faux positifs et blocages | mode `degraded` explicite, preuves, fallback documentés |
| Publication trop tôt | dette publique durable | rester en `0.1.0-dev.x` jusqu'à docs + tests + smoke convergés |
## Matrice d'intégration IA
| Surface | Mode cible | Existant utile | Optimisation IA prioritaire | Garde-fou |
| --- | --- | --- | --- | --- |
| Specs / docs | `assisté` | chaîne 00 -> 04, validation stricte | génération guidée de brief/spec/plan et synchronisation documentaire | `tools/validate_specs.py --strict --require-mirror-sync` |
| Cockpit / TUI | `manuel` puis `assisté` | `refonte_tui`, `full_operator_lane`, `run_alignment_daily` | résumés intelligents, triage d'incidents, suggestions d'action | contrat `cockpit-v1`, logs, sorties JSON |
| Santé MCP / runtime | `piloté` | checks `ready | degraded | blocked` | gateway canonique de santé IA/MCP partagée | preuves horodatées + raisons de dégradation |
| Studio | `assisté` | scan d'agents + artefacts + chat | grounding projet actif, fichiers ouverts, sélection utile, artefacts produit | fallback déterministe, commandes sans modèle pour `/agents` |
| Mesh | `assisté` | commandes de rôles et discovery | vue contrats, dépendances, ownership, handoffs | propagation seulement après validation Studio |
| Operator | `assisté` | runbooks, checks, preuves | briefing opérateur contextualisé, lecture des preuves, raccourcis evidence | aucune action destructive implicite |
| CAD / YiACAD | `manuel` puis `assisté` | lots, audits, forks et TUI dédiées | revue contextualisée et aides au chaînage des lanes | lane isolée + rollback explicite |
## Carte de fonctionnalités
```mermaid
mindmap
root((Kill_LIFE 2026-03-21))
Control Plane
README
docs/index
audit consolidation
Spec-first
00 intake
01 spec
02 arch
03 plan
04 tasks
Cockpit
run_alignment_daily
full_operator_lane
log_ops
mesh_health
Runtime MCP IA
ready/degraded/blocked
registry machines
preuves JSON
Extensions VS Code
Studio produit
Mesh orchestration
Operator evidence
YiACAD
UI/UX
backend
proofs
logs
```
## Benchmark OSS intégré aux décisions
Les références externes les plus actionnables pour cette passe sont:
- `Roo Code`: référence pour les modes spécialisés dans l'éditeur, les agents par rôle et l'usage MCP.
- `OpenHands`: référence pour la séparation claire SDK / CLI / GUI locale / cloud.
- `LangGraph`: référence pour l'orchestration stateful, la mémoire, le `human-in-the-loop` et la reprise d'exécution.
- `modelcontextprotocol/servers` + registre MCP: référence pour les patterns de serveurs, la sécurité d'accès et la découverte outillée.
Le détail de benchmark et les liens de source sont maintenus dans `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`.
## Affectation agents et sous-agents
| Lead | Sous-agents | Compétences | Priorité immédiate |
| --- | --- | --- | --- |
| `PM-Mesh` | `Plan-Orchestrator`, `Risk-Triager`, `Release-Gate` | priorisation, arbitrage, synchro plans/TODOs | baseline sale, P0/P1, barre "prêt avant public" |
| `Docs-Research` | `Doc-Entry`, `Mermaid-Map`, `Feature-Map`, `Runbook-Editor` | consolidation documentaire, benchmark, cartes | README, `docs/index`, `tools/cockpit/README`, `specs/README` |
| `Studio-Product` | `UX-Lead`, `Context-Builder`, `Artifact-Model`, `Extension-Test` | UX auteur, état persistant, grounding, tests | projet actif, contexte chat, artefacts, tests extension-host |
| `Mesh-Contracts` | `Handoff-Guard`, `Contract-View`, `Dependency-Mapper` | contrats multi-repo, ownership, dépendances | reprise du socle Studio validé |
| `Operator-Lane` | `Runbook-Guard`, `Evidence-Runner`, `Log-Ops` | runbooks, evidence, logs, exécution | reprise du socle Studio validé |
| `Runtime-Companion` | `MCP-Health`, `Prompt-Eval`, `Bridge-Queue` | santé runtime/MCP, prompt eval, bridges | gateway canonique `ready/degraded/blocked` |
| `QA-Compliance` | `Contract-Tests`, `Shell-Harness`, `Smoke-E2E` | tests, contrats JSON, smokes | stable suite, tests shell/TUI ciblés, smoke VSIX |
| `OSS-Watch` | `VSCode-Agent-Benchmark`, `Agent-Framework-Benchmark`, `MCP-Benchmark` | veille stratégique et décisions d'adoption | benchmark unique et exploitable |
## Priorités 2026-03-21
### P0
- Consolider les points d'entrée documentaires.
- Installer `tools/cockpit/intelligence_tui.sh` comme point d'entree canonique pour la gouvernance intelligence.
- Stabiliser `kill-life-studio` comme produit pilote.
- Propager le socle de sélection de projet actif et de grounding chat vers Mesh et Operator.
- Tester les contrats JSON des scripts cockpit les plus stables.
### P1
- Poursuivre la spécialisation produit de Mesh et Operator.
- Généraliser les tests shell/TUI à d'autres scripts cockpit.
- Renforcer la preuve multi-root locale pour les extensions.
### P2
- Étendre la gateway de santé IA/MCP en source unique consommable par le cockpit et les extensions.
- Réduire la dette documentaire historique restante.
- Préparer la barre de sortie `v0.1.0` publique sans activer la publication Marketplace avant stabilisation.
## Critères "prêt avant v0.1.0 publique"
- Documentation convergée, avec un seul point d'entrée par surface.
- `kill-life-studio` stabilisé avec tests unitaires + extension-host.
- Mesh et Operator propagés sur le même socle et validés localement.
- Contrats JSON cockpit stables sur les surfaces critiques.
- Smoke multi-root et VSIX rejoués avant tout tag public.
docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md
+55
View File
@@ -0,0 +1,55 @@
# Kill_LIFE consolidation audit (2026-03-22)
## Executive summary
`Kill_LIFE` has a credible 2026 control plane now: spec-first governance, cockpit TUIs, runtime/MCP contracts, YiACAD native surfaces, and a buildable `web/` Git EDA scaffold. The main gap is no longer missing surface area. It is drift between what the docs say is canonical and what the code actually uses for intelligence, review, Git state, artifacts, and realtime.
## Strengths
- spec-first governance is real and still central
- `intelligence_tui` and `runtime_ai_gateway.sh` provide machine-readable continuity
- YiACAD now spans KiCad, FreeCAD, backend service-first hooks, and a web slice
- `web/` installs cleanly and `next build` passes
- core OSS choices are pragmatic: `Excalidraw`, `KiCanvas`, `Yjs`, `BullMQ`, `KiBot`, `KiAuto`
## Weaknesses
- lot 22 was drifting toward "done" while the web Git EDA backlog remained outside the intelligence memory
- docs were underspecifying required contract fields compared with the actual JSON Schemas
- the `web/` save/review/PR path is still filesystem- and JSON-demo-first, not Git-first
- realtime is transport-first only; Excalidraw is not yet bound to Yjs scene state
- worker outputs are not yet surfaced as proper product artifacts
## Opportunities
- use `MCP` and service-first tools for review hints, parts search, artifact fetch, and CI triggers
- expose queue/worker/realtime health inside the intelligence lane instead of keeping web ops isolated
- turn the product review surface into the differentiator: KiCad diff, Excalidraw diff, PCB preview, hints
- keep AI as an overlay on top of Git, Yjs and workers rather than as a competing source of truth
## Risks
- too many overlapping "canonical" sources if plan 22, plan 23 and TUI logic diverge again
- a false sense of Git-native collaboration while writes still bypass Git semantics
- premature AI orchestration before Git, artifacts and realtime read models are closed
- multi-tenant/security debt if `/api/project-files/*` and GraphQL stay too open
## Priority matrix
### P0
- Raccorder la lane intelligence aux sources `web/` et maintenir un backlog vivant `TODO 22 + TODO 23 + specs/04_tasks.md`.
- Remplacer le save/review web purement local par un read model Git minimal et explicite.
- Fermer la boucle `worker -> artifacts -> GraphQL -> UI` avec des URLs web-servables et un etat CI visible.
### P1
- Binder Excalidraw a Yjs sans perdre la discipline snapshot Git.
- Faire remonter le statut `queue/worker/realtime` dans la memoire intelligence et preparer le pont vers `runtime_ai_gateway.sh`.
- Ajouter une premiere surface `review hints / ops summary` en lecture seule.
### P2
- Formaliser le boundary `MCP/service-first` pour parts, artifacts, CI et review assist.
- Revenir sur LangGraph / Agents SDK seulement apres fermeture des P0/P1.
- Ouvrir la couche multi-tenant/auth quand le read model Git/CI est reel.
docs/KILL_LIFE_DIGITAL_FACTORY_SYSTEM_MAP_2026-03-22.md
+396
View File
@@ -0,0 +1,396 @@
# Kill_LIFE — Digital Factory System Map
Date: 2026-03-22
Scope: cadrage produit et technique de `Kill_LIFE` selon le modele `PLM / ERP / MES / WMS / DCS`
Status: working baseline
## 1. Resume
`Kill_LIFE` peut etre lu comme une digital factory logicielle:
- `PLM`: memoire produit, specifications, plans, contrats, cartes de fonctionnalites
- `ERP`: `L'electronrare Ops`, couche de gouvernance operative des ressources, machines, capacites, secrets, priorites
- `MES`: execution des lots, pilotage operateur, orchestration des agents et des actions
- `WMS`: stockage, artefacts, logs, datasets, sorties de handoff et synchronisation de configuration
- `DCS`: controle runtime, sante machine, dispatch P2P, routage de charge, services actifs
L'etat actuel est coherent sur `PLM + MES + DCS`, partiel sur `WMS`, et encore incomplet sur `ERP`.
## 2. Mermaid — architecture cible
```mermaid
graph TD
PLM["PLM\nSpecs · plans · contrats · diagrams · memory"]
ERP["ERP / L'electronrare Ops\nMachines · capacites · priorites · secrets · ownership"]
MES["MES\nCockpit · lots · todos · agents · execution operateur"]
WMS["WMS\nArtifacts · logs · datasets · env sync · handoffs"]
DCS["DCS\nRuntimes · mesh SSH · dispatch P2P · health-check · load balancing"]
PLM <--> ERP
PLM <--> MES
ERP <--> WMS
MES <--> WMS
MES <--> DCS
WMS <--> DCS
```
## 3. Lecture par couche
### 3.1 PLM
Role:
- definir le produit, ses contrats, ses plans et sa memoire de conception
Contenu attendu:
- specifications
- plans de lot
- cartes de fonctionnalites
- diagrammes Mermaid
- README et contrats inter-modules
Etat actuel:
- fort
- deja bien present dans `docs/`, `docs/plans/`, `specs/`
### 3.2 ERP
Role:
- gerer les ressources du systeme global
- decider qui porte quelle charge, avec quelles contraintes et quelles priorites
- porter la couche de gouvernance `L'electronrare Ops`
Reference produit:
- [Ops — L'Electron Rare](https://www.lelectronrare.fr/ops)
Contenu attendu:
- registre machine canonique
- roles et ports par machine
- ordre de priorite de charge
- gouvernance des cles et variables d'environnement
- ownership par lot et par domaine
Etat actuel:
- present mais disperse
- encore trop technique et pas assez formalise comme couche produit
- la surface produit existe deja via `/ops`, mais elle n'est pas encore totalement raccordee aux contrats et scripts internes `Kill_LIFE`
### 3.3 MES
Role:
- piloter l'execution quotidienne
- lancer, suivre, valider et reprendre les lots
Contenu attendu:
- cockpit operateur
- lot chain
- runbooks
- syntheses quotidiennes et hebdomadaires
- attribution d'agents et handoffs
Etat actuel:
- tres fort
- c'est aujourd'hui la couche dominante de `Kill_LIFE`
### 3.4 WMS
Role:
- stocker et rendre retrouvables les objets de travail et de preuve
Contenu attendu:
- artefacts JSON/Markdown
- logs
- datasets fine-tune
- snapshots de run
- synchronisation de secrets/config
Etat actuel:
- fonctionnel mais encore heterogene
- conventions de rangement et TTL partiellement stabilises
### 3.5 DCS
Role:
- controler les runtimes actifs et les noeuds mesh
Contenu attendu:
- health-check SSH
- preflight mesh
- dispatch P2P
- load balancing
- etat des providers et runtimes Mascarade/Ollama
Etat actuel:
- fort
- de nombreux scripts existent deja pour cette couche
## 4. Carte des modules existants
## 4.1 Vue synthese
| Couche | Role principal | Modules / zones existantes |
|---|---|---|
| `PLM` | Conception, contrat, memoire | `docs/`, `docs/plans/`, `specs/` |
| `ERP / L'electronrare Ops` | Gouvernance ressources / machines / secrets | `tools/cockpit/machine_registry.sh`, `tools/cockpit/mistral_workspace_guard.sh`, `tools/cockpit/mascarade_mesh_env_sync.sh`, `tools/cockpit/kill_life_mistral_governance_sync.sh`, `specs/contracts/`, [lelectronrare.fr/ops](https://www.lelectronrare.fr/ops) |
| `MES` | Pilotage execution / lots / agents | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/lot_chain.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/intelligence_tui.sh` |
| `WMS` | Artefacts / logs / datasets / handoffs | `artifacts/`, `tools/cockpit/mascarade_logs_tui.sh`, `tools/cockpit/mascarade_incident_registry.sh`, `tools/cockpit/dataset_audit_tui.sh` |
| `DCS` | Controle runtime / mesh / load balancing | `tools/cockpit/mesh_sync_preflight.sh`, `tools/cockpit/ssh_healthcheck.sh`, `tools/cockpit/mascarade_runtime_health.sh`, `tools/cockpit/mascarade_dispatch_mesh.sh` |
## 4.2 Mapping detaille
### PLM
| Module | Fonction |
|---|---|
| `docs/plans/` | suivi de lot, journal de session, priorites |
| `specs/` | contrats, plan global, backlog, taches |
| `docs/*FEATURE_MAP*` | cartes de fonctionnalites |
| `docs/*CONTRACT*` | contrats produit et techniques |
| `docs/*WEB_RESEARCH*` | veille et decisions appuyees |
### ERP
| Module | Fonction |
|---|---|
| [lelectronrare.fr/ops](https://www.lelectronrare.fr/ops) | couche de gouvernance operatoire metier |
| `tools/cockpit/machine_registry.sh` | registre machine/capacite |
| `tools/cockpit/mistral_workspace_guard.sh` | source de verite de dossier |
| `tools/cockpit/mascarade_mesh_env_sync.sh` | sync `.env` Mascarade sur le mesh |
| `tools/cockpit/kill_life_mistral_governance_sync.sh` | sync secret gouvernance hors repo |
| `specs/contracts/machine_registry.*` | contrat machine canonique |
### MES
| Module | Fonction |
|---|---|
| `tools/cockpit/full_operator_lane.sh` | lane operateur principale |
| `tools/cockpit/run_alignment_daily.sh` | routine quotidienne |
| `tools/cockpit/lot_chain.sh` | enchainement et reprise de lots |
| `tools/cockpit/refonte_tui.sh` | interface TUI de pilotage |
| `tools/cockpit/intelligence_tui.sh` | vue memoire / intelligence |
| `tools/cockpit/render_product_contract_handoff.sh` | point de reprise court canonique |
### WMS
| Module | Fonction |
|---|---|
| `artifacts/` | stockage des preuves et sorties d'execution |
| `tools/cockpit/mascarade_logs_tui.sh` | gestion des logs runtime |
| `tools/cockpit/mascarade_incident_registry.sh` | registre d'incidents |
| `tools/cockpit/render_mascarade_incident_*` | briefs, queue, watch, history |
| `tools/cockpit/dataset_audit_tui.sh` | audit/preflight datasets |
### DCS
| Module | Fonction |
|---|---|
| `tools/cockpit/mesh_sync_preflight.sh` | etat mesh / routage machine |
| `tools/cockpit/ssh_healthcheck.sh` | sante SSH |
| `tools/cockpit/mascarade_runtime_health.sh` | sante runtime Mascarade/Ollama |
| `tools/cockpit/mascarade_dispatch_mesh.sh` | dispatch P2P / charge |
| `tools/cockpit/run_alignment_daily.sh` | pont entre controle runtime et execution operateur |
## 5. Trous de couche
## 5.1 Trous ERP
Manques principaux:
- source de verite unique plus visible pour:
- ownership par lot
- capacite par machine
- role critique / non critique
- budget/provider/secrets par domaine
- pont explicite entre `/ops` et les contrats internes `Kill_LIFE`
- separation partielle seulement entre:
- secret routeur
- secret gouvernance
- secret runtime
- absence d'une table canonique simple:
- `module -> owner -> machine cible -> criticite -> secret scope`
Impact:
- bonne execution locale, mais gouvernance encore trop implicite
- la couche metier existe, mais le raccord `Ops -> contrats -> cockpit` reste incomplet
## 5.2 Trous WMS
Manques principaux:
- conventions de cycle de vie des artefacts encore heterogenes
- index global incomplet entre:
- logs
- handoffs
- watchboards
- datasets
- relation artefact -> lot -> reprise encore dispersée
Impact:
- beaucoup de preuves existent, mais la recuperation reste couteuse
## 5.3 Trous DCS
Manques principaux:
- doublons de racines Mascarade sur certaines machines
- heterogeneite des layouts:
- Linux `/home/...`
- macOS `/Users/...`
- distinction repo/runtime encore ambigue sur `kxkm`
Impact:
- controle bon, mais cout cognitif trop eleve pour les changements de machine
## 5.4 Trous MES
Manques principaux:
- trop de scripts cockpit exposent des vues proches sans index central unique
- certains chemins restent reactifs au lieu d'etre drives par un contrat commun plus strict
Impact:
- execution possible, mais surface encore large et parfois redondante
## 5.5 Trous PLM
Manques principaux:
- il manque une carte produit unique reliant clairement:
- docs
- scripts
- contrats
- couches `PLM/ERP/MES/WMS/DCS`
Impact:
- le sens global existe, mais n'est pas encore assez visible pour une reprise rapide
## 6. Plan de refonte
## 6.1 Objectif
Faire converger `Kill_LIFE` vers un systeme lisible ou:
- `PLM` dit ce qui doit exister
- `ERP` dit avec quelles ressources et quelle gouvernance
- `MES` execute
- `WMS` conserve et retrouve
- `DCS` controle l'etat reel
## 6.2 Priorites
### Phase A — fermer la gouvernance ERP minimale
Objectif:
- transformer la gouvernance technique actuelle en couche explicite
Actions:
- creer une table canonique `machine -> role -> charge -> criticite -> racine active`
- creer une table canonique `secret -> scope -> owner -> consumer`
- raccorder explicitement `L'electronrare Ops` aux contrats internes `Kill_LIFE`
- relier ces tables aux scripts de sync et aux contrats machine
Done attendu:
- plus aucune ambiguite sur:
- quelle machine porte quoi
- quelle racine repo/runtime est la bonne
- quelle cle sert a quel usage
### Phase B — unifier WMS
Objectif:
- rendre tous les artefacts retrouvables et utiles a la reprise
Actions:
- definir une convention unique pour:
- latest
- history
- daily
- weekly
- incidents
- datasets
- construire un index simple `artifact -> lot -> couche -> consumer`
Done attendu:
- un operateur retrouve en une seule vue:
- le dernier etat
- la derniere preuve
- la prochaine action
### Phase C — compacter MES
Objectif:
- reduire la dispersion du cockpit
Actions:
- designer un index operateur central par couche:
- `PLM`
- `ERP`
- `MES`
- `WMS`
- `DCS`
- faire converger les scripts de synthese vers cet index
Done attendu:
- moins de surface, plus de predictibilite
### Phase D — nettoyer DCS
Objectif:
- stabiliser la topologie runtime
Actions:
- choisir une racine Mascarade unique par machine
- documenter les exceptions volontaires
- reduire les doublons `mascarade` / `mascarade-main`
- distinguer explicitement:
- repo de travail
- runtime actif
- dossier de secrets
Done attendu:
- plus de redetection ad hoc des chemins machine
### Phase E — refermer PLM
Objectif:
- rendre la lecture d'ensemble triviale
Actions:
- maintenir ce document comme carte mere
- ajouter des liens croises vers:
- contrats machine
- handoff produit
- plans de lot Mistral
- cartes Mascarade ops
Done attendu:
- reprise possible en lisant une seule page avant d'entrer dans le detail
## 7. Definition de done par couche
| Couche | Done attendu |
|---|---|
| `PLM` | toutes les grandes decisions sont cartographiees et reliees aux modules |
| `ERP` | machines, secrets, capacites, ownership et priorites sont explicites |
| `MES` | un operateur sait quoi lancer, ou reprendre, et avec quel owner |
| `WMS` | chaque execution laisse une preuve indexable et recuperable |
| `DCS` | l'etat runtime reel est visible et raccorde a la machine canonique |
## 8. Prochain lot recommande
Ordre recommande:
1. fermer `ERP` minimal
2. unifier `WMS`
3. compacter `MES`
4. nettoyer `DCS`
5. refermer `PLM`
Traduction immediate en travail:
1. creer un registre canonique `machine / root / secret scope / criticite`
2. creer un index `artifact / lot / couche`
3. exposer un index operateur central par couche
4. normaliser la topologie `mascarade` vs `mascarade-main`
## 9. Related documents
- bridge contract: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/OPS_KILL_LIFE_ERP_BRIDGE_CONTRACT_2026-03-22.md`
- ERP registry: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs/contracts/ops_kill_life_erp_registry.json`
- ERP TUI: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/ops_erp_registry_tui.sh`
- web research: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/WEB_RESEARCH_DIGITAL_FACTORY_STACK_2026-03-22.md`
- WMS artifact index: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/ARTIFACT_WMS_INDEX_2026-03-22.md`
docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md
+68 -67
View File
@@ -1,9 +1,8 @@
# Kill_LIFE Feature Map - 2026-03-11
# Kill_LIFE Feature Map - 2026-03-20
## Scope
Cette carte fixe les surfaces canoniques de `Kill_LIFE` comme repo source de verite spec-first, runtime outille et evidence-first.
Cette feature map sert aussi d'ancre stable pour les prochains diagrammes de sequence et pour le README operateur.
Carte de référence de toutes les surfaces stables du projet, alignée avec le manifeste de refonte.
## Feature map
@@ -11,91 +10,93 @@ Cette feature map sert aussi d'ancre stable pour les prochains diagrammes de seq
flowchart TD
KL[Kill_LIFE]
KL --> SPECS[specs/ canon spec-first]
KL --> WF[workflows/ registry JSON]
KL --> SPECS[specs/ (00_intake -> 04_tasks)]
KL --> PLANS[docs/plans/*]
KL --> WORKFLOWS[workflow lanes + workflow.schema]
KL --> TOOLS[tools/ runtime, validation, CAD/MCP]
KL --> AGENTS[agents/ + .github/agents + prompts]
KL --> BMAD[bmad/ gates + rituels + templates]
KL --> TOOLS[tools/ runtime, validation, CAD, CI]
KL --> HW[hardware/ blocs + regles]
KL --> HW[hardware/ + rules]
KL --> FW[firmware/ PlatformIO]
KL --> COMP[compliance/ profils + evidence]
KL --> OC[openclaw/ sandbox + onboarding]
KL --> DOCS[docs/ operator, plans, evidence]
KL --> COMP[compliance/ + evidence + CI gates]
KL --> DOCS[docs/ operator, evidence, on-boarding]
KL --> GH[.github/workflows + issue templates]
KL --> TEST[test/ verification Python + MCP]
KL --> MCPR[MCP setup + serveur runtime]
KL --> TUI[tools/cockpit]
SPECS --> SPECCHAIN[00_intake -> 01_spec -> 02_arch -> 03_plan -> 04_tasks]
SPECS --> CONSTRAINTS[specs/constraints.yaml]
WF --> WFREG[spec-first / embedded-ci-local / compliance-release]
WF --> WFTPL[templates/*.json]
WF --> WFSCHEMA[workflow.schema.json]
WORKFLOWS --> WF_REG[spec-first.json + embedded-ci-local.json + compliance-release.json]
WORKFLOWS --> WF_SCHEMA[workflow.schema.json]
WORKFLOWS --> WF_CATALOG[.github/workflows/*.yml]
AGENTS --> AG1[PM / Architect / Firmware / QA / Doc / HW]
AGENTS --> AG2[prompts plan_wizard / start / Eureka]
TOOLS --> VS[tools/validate_specs.py]
TOOLS --> CPR[tools/compliance/]
TOOLS --> CAD_RUNTIME[tools/hw/cad_stack.sh + cad_runtime]
TOOLS --> MCP_TOOLS[run_*_mcp.sh + mcp_runtime_status]
TOOLS --> REPO_STATE[tools/repo_state/*]
TOOLS --> CAD_FUSION[tools/cad/ai_native_forks.sh + yiacad_fusion_lot.sh]
TOOLS --> T1[validate_specs + specs]
TOOLS --> T2[cad_runtime + hw/cad_stack + MCP launchers]
TOOLS --> T3[freecad_mcp / openscad / kicad]
TOOLS --> T4[mcp_runtime_status + repo_state + CI audits]
TOOLS --> T5[github dispatch + community + security + quality]
AGENTS --> AG_MERGE[PM / Architect / FW / HW / QA / Doc]
AGENTS --> GITHUB_PROMPTS[.github/prompts/*]
HW --> HW1[hardware/blocks]
HW --> HW2[hardware/rules]
HW --> HW_BLOCKS[blocks + rules + previews]
FW --> FW_SRC[firmware/src]
FW --> FW_TEST[firmware/test]
FW --> FW1[firmware/src]
FW --> FW2[firmware/test]
COMP --> PROFILE[active_profile.yaml + standards]
COMP --> GATES[evidence + checks]
COMP --> C1[active_profile + plan]
COMP --> C2[evidence/*]
COMP --> C3[profiles/* + standards_catalog]
MCPR --> KICAD_MCP[kicad MCP]
MCPR --> VALIDATE_MCP[validate-specs MCP]
MCPR --> GH_DISPATCH[github-dispatch MCP]
MCPR --> DOC_MCP[knowledge-base + freecad + openscad + HF]
MCPR --> MESH[docs/MCP_SETUP.md + docs/MCP_SUPPORT_MATRIX.md]
DOCS --> D1[plans + handoffs + workflows]
DOCS --> D2[evidence + security + rituals]
TUI --> REFONTE_TUI[refonte_tui.sh]
TUI --> LOT_CHAIN[lot_chain.sh + run_next_lots_autonomously.sh]
TUI --> LOGS[artifacts/refonte_tui/*.log]
GH --> G1[18+ GitHub workflows]
GH --> G2[issue templates]
DOCS --> HANDOFFS[handoffs + rituals + workflows docs]
DOCS --> EVIDENCE_DOCS[docs/evidence/*]
WF --> CL[crazy_life editor]
TOOLS --> M[mascarade bridge / ops consumers]
GH --> G_TEMPLATE[templates + issue labels]
GH --> GH_RELEASE[release_signing + repo_state]
TUI --> EXEC[actions auto + log analysis + log purge]
```
## Canonical surfaces
## Surfaces canoniques
| Surface | Role canonique | Anchors |
| Surface | Rôle canonical | Anchors |
| --- | --- | --- |
| `specs/` | chaine spec-first et backlog de reference | `specs/00_intake.md`, `specs/01_spec.md`, `specs/02_arch.md`, `specs/03_plan.md`, `specs/04_tasks.md`, `specs/constraints.yaml` |
| `workflows/` | workflows executables et templates consommes par `crazy_life` | `workflows/spec-first.json`, `workflows/embedded-ci-local.json`, `workflows/compliance-release.json`, `workflows/workflow.schema.json` |
| `agents/` + `.github/agents/` | roles operationnels et contrats agentiques | `agents/*.md`, `.github/agents/*.md`, `.github/prompts/*.md` |
| `bmad/` | discipline de passage entre spec, plan, handoff et gate | `bmad/gates/*`, `bmad/rituals/kickoff.md`, `bmad/templates/*` |
| `tools/` | coeur operatoire du repo: validation, CAD, runtime MCP, CI, hygiene | `tools/validate_specs.py`, `tools/cad_runtime.py`, `tools/mcp_runtime_status.py`, `tools/freecad_mcp.py`, `tools/hw/cad_stack.sh`, `tools/run_github_dispatch_mcp.sh` |
| `hardware/` | blocs reutilisables et regles de bulk edit CAD | `hardware/blocks/`, `hardware/rules/` |
| `firmware/` | implementation embarquee PlatformIO et tests associes | `firmware/src/`, `firmware/test/` |
| `compliance/` | profil actif, plan de conformite et evidence packs | `compliance/active_profile.yaml`, `compliance/plan.yaml`, `compliance/profiles/*`, `compliance/evidence/*` |
| `openclaw/` | couche d'exploitation sandboxee, onboarding et garde-fous d'usage | `openclaw/README.md`, `openclaw/onboarding/*`, `openclaw/local_setup/*` |
| `docs/` | documentation operateur, plans actifs, rituels et preuves | `docs/plans/*`, `docs/workflows/*`, `docs/evidence/*`, `docs/security/*` |
| `.github/workflows/` | automation GitHub allowlistee et gates de depot | `.github/workflows/*.yml` |
| `test/` | verification Python/MCP du repo outille | `test/test_validate_specs.py`, `test/test_github_dispatch_mcp.py`, `test/test_freecad_mcp.py`, `test/test_mcp_runtime_status.py` |
| `specs/` | point d’entrée spec-first | `specs/00_intake.md`, `specs/01_spec.md`, `specs/02_arch.md`, `specs/03_plan.md`, `specs/04_tasks.md`, `specs/constraints.yaml` |
| `docs/plans/*` | contrats opératoires lot-chain | `docs/plans/REPO_DEEP_ANALYSIS_2026-03-11.md`, `docs/plans/12_plan_gestion_des_agents.md`, `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`, `specs/03_plan.md`, `specs/04_tasks.md` |
| `workflows/` | exécutable JSON + schéma | `workflows/spec-first.json`, `workflows/embedded-ci-local.json`, `workflows/compliance-release.json`, `workflow.schema.json` |
| `tools/cockpit/*` | pilotage TUI + lot-chain | `tools/cockpit/refonte_tui.sh`, `tools/autonomous_next_lots.py`, `tools/cockpit/lot_chain.sh`, `tools/run_autonomous_next_lots.sh`, `tools/cockpit/run_next_lots_autonomously.sh` |
| `tools/repo_state/*` | état global + contrat header | `tools/repo_state/collect.py`, `tools/repo_state/repo_refresh.sh`, `tools/repo_state/lint_header_contract.py`, `docs/REPO_STATE_HEADER_CONTRACT.md` |
| `tools/` | outillage runtime | `tools/validate_specs.py`, `tools/compliance/*`, `tools/hw/*`, `tools/mcp_runtime_status.py`, `tools/quality/*` |
| `tools/cad/*` | lot-fusion CAD IA-native | `tools/cad/ai_native_forks.sh`, `tools/cad/yiacad_fusion_lot.sh`, `docs/CAD_AI_NATIVE_FORK_STRATEGY.md` |
| `hardware/` | blocs réutilisables + règles | `hardware/blocks/`, `hardware/rules/` |
| `firmware/` | implémentation embarquée | `firmware/src/`, `firmware/test/` |
| `docs/` | documentation opérateur + evidence | `docs/evidence/*`, `docs/MCP_SETUP.md`, `docs/AI_WORKFLOWS.md`, `docs/index.md` |
| `.github/` | automatisation et prompts | `.github/prompts/`, `.github/agents/`, `.github/workflows/` |
| `test/` | assurance qualité | `test/test_validate_specs.py`, `test/test_github_dispatch_mcp.py`, `test/test_freecad_mcp.py`, `test/test_mcp_runtime_status.py` |
## Execution lanes
## Lignes d’exécution
- spec lane: `specs/00_intake.md` -> `01_spec.md` -> `02_arch.md` -> `03_plan.md` -> `04_tasks.md`
- workflow lane: `workflows/*.json` + `workflow.schema.json` -> edition/validation locale -> execution locale ou dispatch GitHub
- tooling lane: `tools/validate_specs.py` + `tools/compliance/*` + `tools/hw/*` + MCP runtime helpers
- hardware lane: `hardware/blocks` + `hardware/rules` -> `tools/hw/*` -> exports/smokes/evidence
- firmware lane: `firmware/` + tests -> evidence + CI gates
- compliance lane: `compliance/active_profile.yaml` -> standards/evidence -> release readiness
- operator lane: `openclaw/` + `.github/workflows/` + `docs/` -> contribution guidee, sandbox, gate, trace
- spec lane: `specs/00_intake.md` -> ... -> `specs/04_tasks.md`
- workflow lane: workflows JSON -> validation locale -> execution locale/GitHub
- tooling lane: `tools/cockpit/refonte_tui.sh`, `tools/specs/sync_spec_mirror.sh`
- cad fusion lane: `tools/cad/yiacad_fusion_lot.sh` -> `artifacts/cad-fusion`
- hardware lane: `hardware/*` -> `tools/hw/*`
- firmware lane: `firmware/*` -> evidence + CI
- compliance lane: `compliance/*` -> evidence + headers
- operator lane: `.github/workflows/` + docs -> contribution contrôlée
## Source-of-truth contract
## Contrat source-of-truth
- `Kill_LIFE` reste la source de verite pour les specs, workflows, templates, policies de compliance, outillage CAD/MCP et evidence packs.
- `crazy_life` consomme et edite les workflows de `Kill_LIFE`, mais n'en devient pas la source canonique.
- `mascarade` consomme une partie des surfaces runtime/outillage comme repo compagnon d'ops et d'integration, sans remplacer le contrat spec-first de `Kill_LIFE`.
## Current gaps and next lots
- `K-DA-001` est ferme par cette carte versionnee.
- `K-DA-002`: diagramme de sequence `spec -> workflow local -> validation -> evidence`.
- `K-DA-003`: diagramme de sequence `workflow -> github dispatch -> workflow CI -> evidence pack`.
- `K-DA-004`: resynchroniser `README`, `docs/plans` et la doc operateur autour de cette carte.
- `Kill_LIFE` reste la source de vérité des specs, du catalogue workflow, de la gouvernance compliance, de l’outillage et de la carte fonctionnelle.
- `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md` documente les références OSS intégrables.
- Les dépôts compagnon (`mascarade`, `crazy_life`) restent des surfaces d’exploitation, pas de remplacement du contrat local.
docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md
+43 -68
View File
@@ -1,15 +1,15 @@
# Kill_LIFE Workflow GitHub Sequence - 2026-03-11
# Kill_LIFE Workflow GitHub Sequence - 2026-03-20
## Scope
Ce diagramme fixe la sequence canonique quand un workflow `Kill_LIFE` quitte la machine operateur pour passer par le dispatch GitHub et revenir sous forme de statut et d'evidence pack.
Diagramme canonique de la sortie locale vers GitHub Actions, puis retour état + evidence pack.
## Sequence
```mermaid
sequenceDiagram
autonumber
participant OP as Operateur / crazy_life
participant OP as Opérateur / crazy_life
participant WF as workflows/*.json
participant MCP as tools/github_dispatch_mcp.py
participant AL as allowlist dispatch
@@ -18,92 +18,67 @@ sequenceDiagram
participant RS as repo_state.yml
participant EV as evidence_pack.yml
participant REL as release_signing.yml
participant LOG as artifacts/refonte_tui/*.log
participant ART as GitHub artifacts + docs/*
OP->>WF: choisir un workflow canonique versionne
OP->>WF: sélectionner workflow canonique
OP->>MCP: dispatch_workflow(workflow_file, ref, inputs)
MCP->>AL: verifier workflow allowliste + secrets disponibles
AL-->>MCP: autorisation / refus structure
MCP->>AL: vérifier allowlist + secrets
AL-->>MCP: autorisation / refus
alt workflow non allowliste ou secret manquant
MCP-->>OP: erreur structuree missing_secret / dispatch_failed
else workflow autorise
MCP->>GH: workflow_dispatch sur ref cible
GH-->>MCP: accepted + dispatch_id
MCP-->>OP: dispatch accepte, id de suivi
OP->>MCP: get_dispatch_status(dispatch_id)
MCP->>GH: resoudre le run cible
GH-->>MCP: statut queued / in_progress / completed
MCP-->>OP: statut structure du run
alt workflow non allowlist ou secret manquant
MCP-->>OP: refus + code d’erreur
else workflow autorisé
MCP->>GH: workflow_dispatch
GH-->>MCP: accepted + run id
MCP-->>OP: suivi d’exécution
OP->>MCP: get_dispatch_status(run id)
MCP->>GH: résoudre le run target
GH-->>MCP: queued / in_progress / completed
MCP-->>OP: statut + checks
par gates standards
GH->>CI: lancer la suite stable Python
CI-->>ART: logs de suite stable / gate principal
and etat du depot
GH->>RS: generer repo_state
GH->>CI: exécuter test/lint/stable
CI-->>ART: logs + step summary
and état du dépôt
GH->>RS: régénérer repo_state
RS-->>ART: docs/REPO_STATE.md + docs/repo_state.json
and preuves
GH->>EV: lancer la chaine canonique `auto_check_ci_cd.py`
EV-->>ART: snapshot `docs/evidence/*` + artifact `evidence-pack`
and preuve
GH->>EV: exécuter chaîne evidence
EV-->>ART: `artifacts/evidence-pack`
end
opt workflow de release
GH->>REL: release_signing sur tag ou workflow_dispatch
REL-->>ART: artefact signe + release GitHub
GH->>REL: release_signing
REL-->>ART: signature + release
end
GH-->>OP: checks, artifacts, eventuelle release
GH-->>OP: checks + artefacts + eventuels releases
end
```
## Anchors
| Surface | Role dans la sequence GitHub |
| Surface | Rôle |
| --- | --- |
| `workflows/*.json` | choix de la lane et parametrage amont |
| `tools/github_dispatch_mcp.py` | serveur MCP local qui cadre `list_allowlisted_workflows`, `dispatch_workflow`, `get_dispatch_status` |
| `tools/run_github_dispatch_mcp.sh` | launcher stdio du dispatch GitHub |
| `.github/workflows/ci.yml` | gate principal `python-stable` sur la branche ou la PR |
| `.github/workflows/repo_state.yml` | photographie exploitable du repo et artefacts de statut |
| `.github/workflows/evidence_pack.yml` | bootstrap Python + `platformio` repo-local + caches `pip`/`PlatformIO` + evidence lane forcee en `native-pio` + Step Summary |
| `.github/workflows/release_signing.yml` | chemin de release signee par tag ou `workflow_dispatch` |
| `docs/evidence/evidence_pack.md` | contrat minimal et chemins canoniques d'un evidence pack |
| `docs/EVIDENCE_ALIGNMENT_2026-03-11.md` | note d'audit qui ferme l'ecart entre CI, preuves locales et doc |
| `tools/run_github_dispatch_mcp.sh` | façade locale pour l’allowlist dispatch |
| `.github/workflows/ci.yml` | gate principal python-stable |
| `.github/workflows/repo_state.yml` | photo d’état de repo |
| `.github/workflows/evidence_pack.yml` | lane evidence pack et preuve synthétique |
| `.github/workflows/release_signing.yml` | signature éventuelle |
| `docs/evidence/evidence_pack.md` | contrat de lecture des preuves |
| `docs/EVIDENCE_ALIGNMENT_2026-03-11.md` | alignement CI ↔ doc ↔ réalité |
| `tools/repo_state/repo_refresh.sh` | génération du header global |
## Reading
- La machine operateur ne pousse pas elle-meme une logique arbitraire; elle demande le dispatch d'un workflow allowliste.
- Le retour utile n'est pas seulement `success/fail`, mais un ensemble de checks, artefacts et preuves consultables.
- L'artifact `evidence-pack` est un dump de `docs/evidence/`; il reste utile meme si un target sort en `incomplete`.
- La lane evidence GitHub n'a plus besoin du CAD stack Docker pour `PlatformIO`; elle force la voie `native-pio` depuis le venv repo-local.
- Les caches `pip` et `PlatformIO` accelerent la lane sans changer le contrat des preuves produites.
- Le GitHub Step Summary donne une lecture humaine immediate du lane status sans remplacer le JSON d'audit.
- Le sidecar `docs/evidence/ci_cd_audit_summary.md` donne la meme lecture dans l'artifact telechargeable.
- En cas d'echec, le resume Markdown commence par `Focus failures` pour remonter les lanes et signaux prioritaires.
- Les chemins du repo y sont maintenant affiches en relatif pour eviter le bruit machine-specifique.
- Les signaux d'artefacts trop verbeux y sont maintenant resumes en comptes courts pour garder les tableaux lisibles.
- Le resume ajoute maintenant un bloc `Artifact summary` dedie pour separer la lecture des preuves et la lecture des signaux.
- Quand une lane degrade, `Artifact summary` expose aussi les `required_files` et les `missing` lus dans `docs/evidence/<target>/summary.json`.
- `K-DA-018` clarifie maintenant ce bloc en separant `Source artifacts` et `Evidence files`.
- Si `verify_evidence` casse apres une collecte encore marquee `ok`, le resume ajoute `Drift = summary ok` pour rendre visible l'ecart.
- `Kill_LIFE` garde la definition canonique des workflows et de leurs gates; le dispatch n'est qu'un mode d'execution distant.
- Le dispatch GitHub reste la seule voie de validation distante systématique.
- Le retour attendu n’est pas binaire, il inclut check, artefacts et proof summary.
- Le repo-state header est lu depuis `artifacts/repo_state/header.latest.md` et doit contenir au minimum `Kill_LIFE`.
- Les logs TUI (`artifacts/refonte_tui/*.log`) servent au postmortem d’exécution.
## Next lots
- `K-DA-003` est ferme par ce diagramme versionne.
- `K-DA-004`: resynchroniser plus largement README et docs/plans autour des deux sequences `local` et `github`.
- `K-DA-005`: synchroniser la doc operateur avec les preuves et artefacts effectivement exposes.
- `K-DA-006` est ferme par l'alignement du workflow `evidence_pack.yml` avec la chaine reelle `docs/evidence/*`.
- `K-DA-007` est ferme par la voie `native-pio` repo-locale et le durcissement anti-artefacts obsoletes.
- `K-DA-008` est ferme par l'ajout des caches `pip` / `PlatformIO` et du versionnement `requirements-platformio.txt`.
- `K-DA-009` est ferme par la generation du GitHub Step Summary depuis `tools/auto_check_ci_cd.py`.
- `K-DA-010` est ferme par le sidecar Markdown `docs/evidence/ci_cd_audit_summary.md`.
- `K-DA-011` est ferme par la section automatique `Focus failures` dans le resume Markdown.
- `K-DA-012` est ferme par la compaction des chemins absolus dans le rendu Markdown evidence.
- `K-DA-013` est ferme par la reduction des signaux trop verbeux dans le rendu Markdown evidence.
- `K-DA-014` est ferme par le bloc `Artifact summary` dedie dans le rendu Markdown evidence.
- `K-DA-015` est ferme par l'exposition `required_files` / `missing` dans `Artifact summary`.
- `K-DA-016` est ferme par la colonne `Drift` du rendu Markdown evidence.
- `K-DA-017` est ferme par le recalcul de `Artifacts` / `Sample` depuis `summary.json.artifacts` quand `Drift` est detecte.
- `K-DA-018` est ferme par la separation explicite `Source artifacts` / `Evidence files`.
- `K-DA-003` clos par ce diagramme.
- `K-DA-004`: synchroniser les docs opérateur avec les preuves exposées.
- `K-DA-006`, `K-DA-007`: conserver comme preuve continue via `tools/repo_state/*`.
docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md
+42 -43
View File
@@ -1,73 +1,72 @@
# Kill_LIFE Workflow Local Sequence - 2026-03-11
# Kill_LIFE Workflow Local Sequence - 2026-03-20
## Scope
Ce diagramme fixe la sequence locale canonique quand un workflow `Kill_LIFE` est edite, valide et execute sans passage par le dispatch GitHub.
Canonical sequence de validation locale quand un workflow `Kill_LIFE` est édité, validé puis exécuté en local.
## Sequence
```mermaid
sequenceDiagram
autonumber
participant OP as Operateur / crazy_life
participant OP as Opérateur / crazy_life
participant TUI as tools/cockpit/refonte_tui.sh
participant WF as workflows/*.json
participant SCHEMA as workflow.schema.json
participant VS as tools/validate_specs.py
participant COMP as tools/compliance/validate.py
participant RUNTIME as tools/mcp_runtime_status.py
participant CAD as tools/cad_runtime.py / tools/hw/*
participant RUNS as .crazy-life/runs
participant MCP as tools/mcp_runtime_status.py
participant RUNTIME as tools/cad_runtime.py / tools/hw/*
participant LOG as artifacts/refonte_tui/*.log
participant EVID as docs/evidence / compliance/evidence
OP->>WF: creer ou modifier un workflow canonique
OP->>SCHEMA: valider la structure JSON du workflow
SCHEMA-->>OP: workflow structurellement valide / invalide
OP->>WF: edit / créer workflow canonique
OP->>SCHEMA: valider schéma
SCHEMA-->>OP: valide / invalide
OP->>VS: lancer validation spec-first
VS-->>OP: synthèse OK / FAIL
OP->>COMP: lancer validation conformité
COMP-->>OP: profile actif + blockers
OP->>MCP: vérifier prérequis MCP/CAD locaux
MCP-->>OP: statut runtime local
OP->>VS: lancer la validation spec-first
VS->>VS: verifier 03_plan / 04_tasks / constraints / RFC2119
VS-->>OP: synthese OK / FAIL + ecarts
OP->>COMP: lancer la validation compliance
COMP->>COMP: charger active_profile + standards + evidence attendues
COMP-->>OP: statut compliance et blockers
OP->>RUNTIME: verifier les prerequis MCP/runtime locaux
RUNTIME-->>OP: statut global, blockers, optional degraded
alt workflow implique du CAD ou du hardware
OP->>CAD: lancer doctor / export / smoke / schops
CAD-->>OP: artefacts locaux et statut outillage
alt workflow implique hardware/CAD
OP->>RUNTIME: lancer doctor / export / smoke / schops
RUNTIME-->>OP: artefacts locaux
end
OP->>RUNS: ecrire le run local et son etat
RUNS-->>OP: historique local / restore possible
alt opérateur lance via TUI
OP->>TUI: lancer readme_audit / lot-chain / status
TUI->>LOG: écrire log
TUI-->>OP: sortie + état
end
OP->>EVID: deposer les preuves locales utiles
EVID-->>OP: evidence pack exploitable pour revue ou bascule GitHub
OP->>EVID: déposer preuves locales
EVID-->>OP: dossiers exploitables pour revue
```
## Anchors
| Surface | Role dans la sequence locale |
| Surface | Role |
| --- | --- |
| `workflows/*.json` | definition executable et versionnee de la lane |
| `workflows/workflow.schema.json` | validation structurelle avant execution |
| `tools/validate_specs.py` | garde spec-first locale |
| `tools/compliance/validate.py` | validation du profil actif et des preuves attendues |
| `tools/mcp_runtime_status.py` | lecture de sante des runtimes MCP/CAD locaux |
| `tools/cad_runtime.py` et `tools/hw/*` | actions locales hardware/CAD quand le workflow en depend |
| `.crazy-life/runs/` | etat local des runs depuis l'editeur `crazy_life` |
| `.crazy-life/backups/workflows/` | revisions et restores locaux non versionnes |
| `docs/evidence/` et `compliance/evidence/` | sortie documentaire exploitable pour revue et transition release |
| `workflows/*.json` | définition executable et versionnée |
| `workflow.schema.json` | vérification structurelle |
| `tools/validate_specs.py` | garde-fou spec-first |
| `tools/compliance/validate.py` | validation profile + compliance |
| `tools/mcp_runtime_status.py` | état des runtimes MCP/CAD |
| `tools/hw/*` | actions hardware/CAD si workflow dépendant |
| `tools/cockpit/refonte_tui.sh` | exécute lot-chain et garde les logs |
| `artifacts/refonte_tui/*.log` | lecture/analyse/suppression contrôlée |
| `docs/evidence/*` | preuves pour revue |
## Reading
- La validation locale ne remplace pas le dispatch GitHub; elle sert de sas avant CI distante.
- `Kill_LIFE` conserve la source de verite des workflows et des regles de validation.
- `crazy_life` joue le role d'editeur et d'operateur local, mais les artefacts canoniques restent dans `Kill_LIFE`.
- La validation locale est un prérequis, pas un remplacement de la validation GitHub.
- `KILL_LIFE` garde la source de vérité des workflows et règles de validation.
- Le TUI agit comme couche opératoire uniforme pour status, logs et lots.
## Next lots
- `K-DA-002` est ferme par ce diagramme versionne.
- `K-DA-003`: sequence `workflow github` avec allowlist dispatch et evidence pack CI.
- `K-DA-004`: synchroniser README et doc operateur autour des deux diagrammes `local` et `github`.
- `K-DA-002` est fermé par ce diagramme versionné.
- `K-RE-002` fermera la dette cartes/séquences restantes.
- Enchaîner ensuite avec `K-DA-003` côté GitHub.
docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md
+121
View File
@@ -0,0 +1,121 @@
# Contrat d’alignement inter-machines — Kill_LIFE
Date: `2026-03-20`
Objectif: maintien d’une base commune opérationnelle sur les 4 cibles SSH et la stratégie de répartition de charge.
Ordre de pilotage opérationnel cible:
1. `clems@192.168.0.120` (Tower)
2. `kxkm@kxkm-ai` (KXKM)
3. `cils@100.126.225.111` (CILS, usage non essentiel)
4. Local (`/Users/electron/Documents/Lelectron_rare/Kill_LIFE`)
5. `root@192.168.0.119` (Réserve de reprise)
## État de base (contrôles de référence)
- `git` commit attendu (branche `main`): `bd3f7b99154f86057ba18b9948d940df55722b12`
- Remote attendu: `https://github.com/electron-rare/Kill_LIFE.git`
- Script de maintenance attendu: `tools/repo_state/repo_refresh.sh`
- Port SSH attendu: `22` (toutes machines)
- Source machine-readable associée: `specs/contracts/machine_registry.mesh.json`
## Contrat machine
### Politique de répartition de charge P2P
- Ordre de charge prioritaire de base: `Tower (clems)` -> `KXKM` -> `CILS` -> `local` -> `root`.
- Le scheduler calcule un score `load_ratio = loadavg / CPUs`, puis `score = priorité_base + int(load_ratio * 1000)` et réordonne les hôtes par score croissant.
- `root` reste la cible de reprise si les 3 premiers sont surchargés, hors cas dégradés.
- `root` est strictement maintenu en réserve: il ne remonte pas devant `local` dans le `host_order` tant que `tower-first` fonctionne.
- En surcharge (par défaut `load_ratio > 1.8`), seuls les contrôles critiques (`Kill_LIFE`) sont exécutés.
- `cils` est verrouillé en opération standard (`tower-first`) : seul `Kill_LIFE` est vérifié.
- `cils` en mode `photon-safe` ne reçoit **aucun** précheck applicatif (charge totale zéro, uniquement reachabilité SSH implicite).
- `CILS` reste hôte secondaire (photon): pas d’hébergement de services essentiels persistants; seulement les snapshots critiques (`Kill_LIFE`) sont acceptés en `tower-first`.
- `root` est la réserve de calcul pour reprendre le relais en cas de besoin (pas cible prioritaire).
- `root` reste en réserve de capacité de calcul pour les bascules de charge.
- En cas de doute opérationnel, forcer `--load-profile photon-safe` pour les préchecks.
### Spécification hôtes
- `clems@192.168.0.120`
- rôle: machine de pilotage / orchestration locale
- port: `22`
- path repo: `/home/clems/Kill_LIFE-main`
- priorité: `1`
- état cible: Git repo proprement monté, branche `main`, commit cible, `SCRIPT_OK`
- `kxkm@kxkm-ai`
- rôle: Mac opérateur
- port: `22`
- path repo: `/home/kxkm/Kill_LIFE-main`
- priorité: `2`
- état cible: Git repo proprement monté, branche `main`, commit cible, `SCRIPT_OK`
- `cils@100.126.225.111`
- rôle: Mac opérateur secondaire
- port: `22`
- path repo: `/Users/cils/Kill_LIFE-main`
- priorité: `3`
- état cible: Git repo proprement monté, branche `main`, commit cible, `SCRIPT_OK`
- contrainte: ne pas y héberger de services persistants critiques; en `tower-first`, précheck non-essentiel verrouillé (`cils-lockdown`) ; en `photon-safe`, aucun précheck applicatif SSH-only.
- `root@192.168.0.119`
- rôle: serveur système / exécution matérielle
- port: `22`
- path repo: `/root/Kill_LIFE-main`
- priorité: `5`
- état cible: Git repo proprement monté, branche `main`, commit cible, `SCRIPT_OK`
## Health-check SSH (référence opérationnelle)
- Exécuter depuis la machine pilote:
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- Sorties attendues:
- un statut `OK`/`KO` par entrée
- rôle et port associés à chaque cible
- cibles SSH résolues depuis `specs/contracts/machine_registry.mesh.json` (`local` exclu automatiquement car port `0`)
- fichier log horodaté `artifacts/cockpit/ssh_healthcheck_<YYYYMMDD>_<HHMMSS>.log`
- Matrix opérationnelle cible:
- P1 `clems@192.168.0.120` (`22`) → rôle `Machine de pilotage / orchestration locale`
- P2 `kxkm@kxkm-ai` (`22`) → rôle `Mac opérateur`
- P3 `cils@100.126.225.111` (`22`) → rôle `Mac opérateur secondaire`
- P4 `root@192.168.0.119` (`22`) → rôle `Serveur système / exécution matérielle`
## Check-list de conformité (quotidienne)
1. `bash tools/cockpit/ssh_healthcheck.sh --json`
2. `cd /home/<user>/Kill_LIFE-main && git status --short` (ou équivalent remote via SSH)
3. `bash tools/repo_state/repo_refresh.sh --header-only`
4. Vérifier que `docs/REPO_STATE.md` et `docs/repo_state.json` restent cohérents avec la source de vérité
## Règles de dérive
- Les changements locaux non souhaités sur `Kill_LIFE` sont prohibés hors workflow défini.
- Les références obsolètes de machine/référence doivent être retirées du périmètre opérationnel avant publication.
- En cas de divergence commit:
- trancher sur la branche/commit cible (standard: `origin/main`)
- documenter la déviation dans `docs/MACHINE_SYNC_STATUS_2026-03-20.md`
- réaligner via `git fetch --all --prune && git reset --hard origin/main`
## Routine quotidienne de contrôle
- Exécuter une fois par jour:
- Machine de pilotage: `bash tools/cockpit/run_alignment_daily.sh --json --mesh-load-profile tower-first`
- Machines de support: `bash tools/cockpit/run_alignment_daily.sh --skip-healthcheck --skip-mesh --json`
- Cibles élargies: `clems`, `kxkm`, `cils`, `root`
- Optionnel: `--purge-days <N>` pour ajuster la rétention des logs (défaut: `14`)
- Optionnel: forcer le mode `photon-safe` sur une exécution spécifique :
- `bash tools/cockpit/run_alignment_daily.sh --json --skip-healthcheck --mesh-load-profile photon-safe`
- Exemple cron:
- `05 06 * * * cd /chemin/vers/Kill_LIFE && bash tools/cockpit/run_alignment_daily.sh --json --purge-days 14 >> artifacts/cockpit/cron.out 2>&1`
- Logs:
- `artifacts/cockpit/machine_alignment_daily_<YYYYMMDD>_<HHMMSS>.log`
## Sortie de dérogation
- Toute machine hors contrat doit être remontée immédiatement avec:
- machine/port
- rôle
- écart constaté
- preuve de commande
- ETA de remise en conformité
docs/MACHINE_REGISTRY_2026-03-20.md
+51
View File
@@ -0,0 +1,51 @@
# Registre machine/capacite — Kill_LIFE
Date: `2026-03-20`
Source de verite machine-readable:
- `specs/contracts/machine_registry.mesh.json`
- schema: `specs/contracts/machine_registry.schema.json`
Objectif: publier un registre unique pour les roles, ports, priorites et restrictions de placement afin de reduire le drift entre documentation, preflight mesh et runbooks cockpit.
## Contenu porte par le registre
- id machine stable
- cible SSH ou label local
- role operatoire
- port
- priorite de scheduling
- type de placement (`primary`, `secondary`, `quota`, `local`, `reserve`)
- profils actifs (`tower-first`, `photon-safe`)
- liste des repos critiques autorises
- politique non essentielle
- drapeau `reserve_only`
- biais d'ordre de charge
## Ordre canonique actuel
1. `tower` -> `clems@192.168.0.120`
2. `kxkm` -> `kxkm@kxkm-ai`
3. `cils` -> `cils@100.126.225.111`
4. `local`
5. `root-reserve` -> `root@192.168.0.119`
## Regles operatoires encodees
- `cils` reste en quota et ne porte que `Kill_LIFE` en critique.
- `photon-safe` garde `cils` atteignable, mais sans charge applicative non essentielle.
- `root-reserve` reste une reserve stricte et ne remonte pas devant `local` en fonctionnement nominal.
## CLI cockpit associee
- `bash tools/cockpit/machine_registry.sh --action summary --json`
- `bash tools/cockpit/machine_registry.sh --action list`
- `bash tools/cockpit/machine_registry.sh --action show --machine cils --json`
- `bash tools/cockpit/machine_registry.sh --action clean-logs --days 14`
## Suite prevue
- `mesh_sync_preflight.sh` consomme maintenant ce registre pour les roles, ports, priorites, placement et la reserve runtime
- `ssh_healthcheck.sh` charge maintenant ses cibles SSH directement depuis le registre et ignore automatiquement l'entree `local` (port `0`)
- `run_alignment_daily.sh` capture maintenant un resume JSON du registre et l'embarque dans ses artefacts/JSON de synthese
- externaliser ensuite les derniers candidats de chemins repo pour eliminer le drift restant cote preflight
docs/MACHINE_SYNC_STATUS_2026-03-20.md
+451
View File
@@ -0,0 +1,451 @@
# Etat de synchronisation machines et repos (2026-03-20)
Last updated: 2026-03-20 15:33:32 Europe/Paris
## Résumé opérationnel
- `run_alignment_daily.sh` OK sur les 4 machines ciblées.
- `ssh_healthcheck --json` OK sur les 4 destinations.
- `full_operator_lane` est valide sur `clems` en `dry-run` et en `live`.
- `mesh_sync_preflight --json` a été corrigé en cours (robustesse parsing remote `snapshot_repo_remote`) ; nouvelle passe de vérification en cours.
- `run_alignment_daily.sh --json --mesh-load-profile tower-first` inclut désormais `log_ops` (résumé + purge contrôlée), avec purge TTL optionnelle.
- `cils` reste hors charge essentielle en priorité: seules opérations critiques `Kill_LIFE` en mode default, puis préchecks non-critiques en saturation.
- `mesh_health_check --json` expose désormais `mesh_host_order` pour tracer la décision P2P `Tower -> KXKM -> CILS -> local -> root` (root réservé).
- Règle opératoire active: éviter toute charge essentielle sur `cils@100.126.225.111`, et basculer `photon-safe` en cas de tension.
- `mesh_health_check --load-profile tower-first --json` exécuté: `status=degraded`, `mesh_host_order=clems -> kxkm -> cils -> local -> root`, `readme_findings=2` (preuve: `artifacts/cockpit/health_reports/mesh_health_check_mesh_20260320_153202.json`).
- `run_alignment_daily --json --mesh-load-profile tower-first` exécuté: `result=degraded`, `mesh_status=degraded`, preuve `artifacts/cockpit/machine_alignment_daily_20260320_152957.json`.
- `ssh_healthcheck --json` exécuté: `4 OK / 0 KO`, preuve `artifacts/cockpit/ssh_healthcheck_20260320_150115.log`.
Note d'alignement: la fenêtre ci-dessus reste en consolidation tant que l’exécution de preuve post-correction n’a pas confirmé `mesh_status=ready` sur `clems` avec la charge cible.
## Logs clés de la fenêtre de référence
- `artifacts/refonte_tui/refonte_tui_20260320_102553.log` (log_ops summary, pas de stale)
- `artifacts/refonte_tui/refonte_tui_20260320_102742.log` (mesh + SSH)
- `artifacts/refonte_tui/refonte_tui_20260320_103117.log` (preflight + tests)
- `artifacts/refonte_tui/refonte_tui_20260320_104305.log` (logs/lecture + purge)
- `artifacts/cockpit/mesh_sync_preflight_20260320_103117.log`
- `artifacts/cockpit/mesh_sync_preflight_20260320_103718.log`
- `artifacts/cockpit/mesh_sync_preflight_20260320_104308.log` (entrée d’exécution, préflight lancé)
- `artifacts/cockpit/ssh_healthcheck_20260320_103818.log`
- `artifacts/cockpit/refonte_tui.log` (agrégat local de session TUI)
## Observation operatoire 2026-03-20 15:33 +0100
- `mesh_health_check --load-profile tower-first --json` exécuté: `status=degraded`, `mesh_host_order=clems@192.168.0.120,kxkm@kxkm-ai,cils@100.126.225.111,local,root@192.168.0.119`.
- `run_alignment_daily --json --mesh-load-profile tower-first` exécuté: `result=degraded`, preuve `artifacts/cockpit/machine_alignment_daily_20260320_152957.log`.
- CILS est bien traité en mode `cils-lockdown` (kill-life ok, mascarade/crazy_life skip), et l’ordre de charge reste `tower-first`.
- `cils` continue de maintenir la priorité de charge tout en étant protégé des services non essentiels.
## Observations par machine
### `clems@192.168.0.120`
- Repo `Kill_LIFE`: `main`, branche commune, `dirty=8`
- Repo `mascarade`: `main`, `dirty=0`
- Repo `crazy_life`: `main`, `dirty=0`
### `root@192.168.0.119`
- Repo `Kill_LIFE`: `main`, `dirty=8`
- Repo `mascarade`: `main`, `dirty=0`
- Repo `crazy_life`: `main`, `dirty=0`
### `kxkm@kxkm-ai`
- Repo `Kill_LIFE`: `main`, `dirty=8`
- Repo `mascarade`: `main`, `dirty=0`
- Repo `crazy_life`: `main`, `dirty=0`
### Local (`/Users/electron/Documents/Lelectron_rare/Kill_LIFE`)
- Repo `Kill_LIFE`: `main`, `dirty=61` (fichier locaux de refonte/docs)
- `ai-agentic-embedded-base/specs/` synchronisé avec `specs/`.
- Repo `mascarade-main`: `main`, `dirty=0`
## Commandes de preuve
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/refonte_tui.sh --action logs`
- `bash tools/cockpit/refonte_tui.sh --action log-ops`
## Recommandation court terme
- Maintenir en mode `degraded` tant que `Kill_LIFE` local ne descend pas sous `dirty=8`.
- Continuer le lot `zeroclaw-integrations` puis `mesh-governance` avec `specs/04_tasks.md` pour remonter la convergence.
## Observation operatoire 2026-03-20 11:57 +0100
Preuve: `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat observe apres normalisation `Kill_LIFE-main`:
- `mesh_status=ready`
- `Kill_LIFE=ready`
- `mascarade=ready`
- `crazy_life=ready`
Normalisation `Kill_LIFE-main` effectuee sans ecraser les worktrees existantes:
- local: `/Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/Kill_LIFE-main`
- `clems@192.168.0.120`: `/home/clems/Kill_LIFE-main`
- `root@192.168.0.119`: `/root/Kill_LIFE-main`
- `kxkm@kxkm-ai`: `/home/kxkm/Kill_LIFE-main`
Etat `Kill_LIFE-main` observe:
- branche `main`
- SHA `bd3f7b99154f86057ba18b9948d940df55722b12`
- dirty-set `0` sur les quatre miroirs mesh
La lane mesh est maintenant propre et convergente sur les trois repos observes par le preflight.
## Observation operatoire 2026-03-20 12:00 +0100
Propagation documentaire mesh engagee sur les repos compagnons:
- `mascarade-main`: contrat runtime mesh + todo mesh dediee
- `crazy_life-main`: contrat web mesh + todo mesh dediee
Lanes mesh reservees pour `crazy_life`:
- local: `/Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/crazy_life-main`
- `clems@192.168.0.120`: `/home/clems/crazy_life-main`
- `root@192.168.0.119`: `/root/crazy_life-main`
- `kxkm@kxkm-ai`: `/home/kxkm/crazy_life-main`
La propagation s'effectue par miroirs dedies, sans ecraser les worktrees historiques.
## Observation operatoire 2026-03-20 12:23 +0100
Preuve: `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat final observe apres propagation companion + lanes `crazy_life-main`:
- `mesh_status=ready`
- `Kill_LIFE=ready`
- `mascarade=ready`
- `crazy_life=ready`
Lanes mesh convergentes:
- `Kill_LIFE-main` sur local, `clems`, `root`, `kxkm-ai`, `cils`
- `mascarade-main` sur local, `clems`, `root`, `kxkm-ai`
- `crazy_life-main` sur local, `clems`, `root`, `kxkm-ai`
Propagation documentaire companion observee sur les miroirs:
- `mascarade-main`: `README.md`, `docs/TRI_REPO_MESH_RUNTIME_CONTRACT_2026-03-20.md`, `docs/TODO_MESH_TRI_REPO_2026-03-20.md`
- `crazy_life-main`: `README.md`, `docs/TRI_REPO_MESH_WEB_CONTRACT_2026-03-20.md`, `docs/TODO_MESH_TRI_REPO_2026-03-20.md`
Le mesh reste `ready` parce que les dirty-sets des miroirs dedies sont alignes repo par repo sur toutes les machines.
## Observation operatoire 2026-03-20 12:35 +0100
Ajout d'une quatrieme cible SSH operateur:
- `cils@100.126.225.111`
Integration effectuee en mode conservateur:
- sauvegarde de la lane partielle `Kill_LIFE-main` creee lors du premier essai de clone:
- `/Users/cils/Kill_LIFE-main.partial-20260320_123103`
- creation de miroirs mesh dedies sans toucher aux worktrees historiques:
- `/Users/cils/Kill_LIFE-main`
- `/Users/cils/mascarade-main`
- `/Users/cils/crazy_life-main`
- propagation realisee depuis les miroirs locaux par archive `tar`, sans dependre d'un `git clone` sur la machine distante
Attendu pour la passe suivante:
- etendre `ssh_healthcheck` a `cils`
- relancer le preflight tri-repo avec cette nouvelle cible
## Observation operatoire 2026-03-20 12:41 +0100
Preuves:
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat consolide apres integration de `cils` et correction de portabilite du preflight:
- `ssh_healthcheck`: `4/4 OK`
- `mesh_status=ready`
- `Kill_LIFE=ready`
- `mascarade=ready`
- `crazy_life=ready`
Cibles mesh convergentes:
- `clems@192.168.0.120`
- `root@192.168.0.119`
- `kxkm@kxkm-ai`
- `cils@100.126.225.111`
Correctif operatoire applique:
- le snapshot distant du preflight utilise desormais `bash -s` au lieu de dependre du shell distant par defaut
- la compatibilite est ainsi preservee sur les hotes ouvrant en `zsh`, dont `cils`
## Observation operatoire 2026-03-20 12:52 +0100
Lot companion + IA contract termine:
- `mascarade-main`: preflight local `scripts/mesh_runtime_preflight.sh`
- `crazy_life-main`: preflight local `scripts/mesh_web_preflight.sh`
- `Kill_LIFE`: schemas machine-readables publies pour `agent_handoff`, `repo_snapshot`, `workflow_handshake`
- `Kill_LIFE`: checker local `tools/specs/mesh_contract_check.py`
Preuves:
- `bash /Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/mascarade-main/scripts/mesh_runtime_preflight.sh --json`
- `bash /Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/crazy_life-main/scripts/mesh_web_preflight.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat final observe apres propagation sur local, `clems`, `root`, `kxkm-ai`, `cils` et purge des logs locaux de preflight:
- `mesh_status=ready`
- `Kill_LIFE=ready`
- `mascarade=ready`
- `crazy_life=ready`
## Observation operatoire 2026-03-20 13:03 +0100
Branchement du checker mesh confirme sans exclusivite d'ecriture:
- `tools/autonomous_next_lots.py` consomme maintenant les contrats `agent_handoff`, `repo_snapshot`, `workflow_handshake`
- les preflights compagnons consomment les schemas depuis la lane soeur `Kill_LIFE-main`
- `.github/workflows/mesh_contracts.yml` rend la validation CI visible
Preuves:
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/agent_handoff.schema.json --instance specs/contracts/examples/agent_handoff.mesh.json`
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/repo_snapshot.schema.json --instance specs/contracts/examples/repo_snapshot.mesh.json`
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/workflow_handshake.schema.json --instance specs/contracts/examples/workflow_handshake.mesh.json`
- execution explicite du lot `mesh-governance` via `tools/autonomous_next_lots.py`
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat observe:
- lot `mesh-governance`: `5` validations `done`, `0` advisory, `0` blocked
- `mesh_status=ready`
- `Kill_LIFE=ready`
- `mascarade=ready`
- `crazy_life=ready`
## Observation operatoire 2026-03-20 13:34 +0100
Preuves:
## Observation operatoire 2026-03-20 14:33 +0100
Preuves:
- `bash tools/cockpit/full_operator_lane.sh dry-run --json`
- `bash tools/cockpit/full_operator_lane.sh live --json`
Etat observe sur `clems@192.168.0.120`:
- `dry-run`: `success`
- `run_id=4a9adf87-1695-4321-86a2-e066a0988533`
- `live`: `success`
- `run_id=5ef4909f-8747-4634-a6a6-d131692787b0`
- provider final: `claude`
- model final: `claude-sonnet-4-6`
Correctifs ayant permis la validation:
- remplacement du runner Python par `tools/ops/operator_live_provider_smoke.js` pour l'execution dans `mascarade-api`
- payload runtime aligne sur le contrat observe (`system` top-level)
- mode par defaut sans `model` force, pour laisser le runtime choisir son provider sain
## Observation operatoire 2026-03-20 14:45 +0100
## Observation operatoire 2026-03-20 16:21 +0100
Preuves:
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/run_alignment_daily.sh --json --skip-mesh --skip-log-ops --no-purge`
Etat observe:
- `ssh_healthcheck`: `4/4 OK`
- `target_source=registry`
- `run_alignment_daily`: `result=ok`, `mesh_status=skipped`
- `registry_summary_status=ok`
- `registry_target_count=5`
- `registry_default_profile=tower-first`
Delta operatoire:
- le registre machine/capacite est maintenant consomme directement par `ssh_healthcheck.sh`
- `run_alignment_daily.sh` embarque maintenant un artefact dedie `machine_registry_summary_<timestamp>.json`
- la source de verite machine-readable est donc effectivement branchee sur les deux runbooks operator centraux
Point de vigilance separe:
- la lane `yiacad-fusion` reste `blocked` cote KiCad host, non pas a cause du mesh, mais parce que `mascarade-main/finetune/kicad_mcp_server/dist/index.js` n'est pas materialise dans ce checkout
- le launcher KiCad recadre maintenant `REQUESTED_RUNTIME=auto` vers `SELECTED_RUNTIME=container` tant que cet entrypoint manque
Preuve:
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat consolide apres validation E2E:
- `mesh_status=blocked`
- `Kill_LIFE=blocked`
- `mascarade=degraded`
- `crazy_life=blocked`
Causes observees:
- `clems@192.168.0.120:/home/clems/Kill_LIFE-main` ne remonte plus comme snapshot Git exploitable pour le preflight
## Observation operatoire 2026-03-20 15:58 +0100
- Preuve:
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile photon-safe --json`
- `bash tools/cockpit/run_alignment_daily.sh --json --mesh-load-profile tower-first --skip-healthcheck`
- Corrections livrées dans le lot:
- parsing distant robuste dans `snapshot_repo_remote` (trim/normalisation + parse tolérant aux sorties SSH inattendues)
- ordre de log ops désormais intégré au runbook quotidien avec `log_ops` résumé et purge contrôlée (`--retain`/`--purge`).
- Attendu de convergence:
- confirmation `mesh_status` de `mesh_sync_preflight` après propagation locale (`kill-life`/`crazy_life`) stable sur `clems`, `root`, `kxkm`, `cils`.
- `clems@192.168.0.120:/home/clems/crazy_life-main` ne remonte plus comme snapshot Git exploitable pour le preflight
- `cils` reste volontairement en `degraded` pour `mascarade` et `crazy_life` en mode `cils-lockdown`
- les lanes companions portent maintenant des deltas docs/code legitimes, avec presence de fichiers `._*` sur certaines machines
Decision operatoire:
- conserver la lane live validee sur `clems`
- traiter le lot suivant en mode conservateur: propagation documentee via `tools/cockpit/full_operator_lane_sync.sh`
- ne pas ecraser les worktrees non-mesh tant que la visibilite `clems` n'est pas retablie
## Observation operatoire 2026-03-20 14:58 +0100
Preuves:
- `bash tools/cockpit/full_operator_lane_sync.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
Etat consolide apres propagation staged:
- `mesh_status=degraded`
- `Kill_LIFE=degraded`
- `mascarade=degraded`
- `crazy_life=degraded`
Evolutions observees:
- `Kill_LIFE-main` sur `clems` remonte a nouveau comme snapshot Git exploitable
- `crazy_life-main` sur `clems` remonte a nouveau comme snapshot Git exploitable
- le point restant sur `clems` est `mascarade-main`, encore `degraded`
- `cils` reste volontairement `degraded` pour `mascarade` et `crazy_life` a cause de `cils-lockdown`
Resultat operatoire:
- le lot `post-E2E hardening` n'est plus bloque
- la suite doit se faire en mode `controlled lots` tant que le mesh global reste `degraded`
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first --json`
- `bash tools/cockpit/run_alignment_daily.sh --json --skip-healthcheck --mesh-load-profile tower-first`
Résultat:
- Health-check SSH: `4 OK / 0 KO`
- `mesh_sync_preflight --json --load-profile tower-first`:
- `mesh_status=degraded`
- `repo Kill_LIFE: ready`
- `repo mascarade: degraded`
- `repo crazy_life: degraded`
- La dégradation est attendue: non-blocage `cils-lockdown` sur `mascarade` et `crazy_life` pour éviter la surcharge de `cils`.
- ordre de charge observé: `clems@192.168.0.120` → `kxkm@kxkm-ai` → `local` → `cils@100.126.225.111` → `root@192.168.0.119`
## Observation operatoire 2026-03-20 16:54 +0100
Preuves:
- `bash tools/cockpit/full_operator_lane_sync.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --json --load-profile tower-first`
- `bash tools/cockpit/mesh_health_check.sh --json --load-profile tower-first`
Etat observe:
- `full_operator_lane_sync`: `status=done`, `targets=4`
- `mesh_sync_preflight`:
- `clems/Kill_LIFE-main`: `ready`
- `clems/mascarade-main`: `ready`
- `clems/crazy_life-main`: `ready`
- `mesh_health_check`:
- `registry_status=ready`
- `readme_status=ready`
- `log_status=ready`
- `mesh_status=degraded`
Conclusion:
- la visibilite preflight sur `clems` est restauree pour le patchset `post-E2E hardening`
- le residuel `mesh_status=degraded` ne vient plus du lot operateur, mais de:
- `cils-lockdown` volontaire sur `mascarade` et `crazy_life`
- la convergence encore imparfaite de certains `dirty_count`
- le probe de charge `clems` actuellement note `degraded:invalid-load-output`
- `run_alignment_daily --json --skip-healthcheck --mesh-load-profile tower-first`:
- `result=ok`
- `mesh_status=degraded`
Piste d’action:
- garder `cils` en mode lock (`photon-safe`) tant que ses ressources restent limitées;
- conserver la progression par lots en `degraded` contrôlé, avec convergence complète uniquement sur `Kill_LIFE` pour les cycles critiques.
## Delta 2026-03-20 14:20 - full operator lane staged
- `Kill_LIFE` now carries the workflow `embedded-operator-live`, the live-provider smoke bridge, the operator evidence contract and the dedicated TUI runbook.
- `crazy_life-main` consumes the local action `operator.live-provider` and exposes the evidence through the existing `/api/killlife/*` lane.
- `mascarade-main` keeps the runtime bridge stable on `/api/v1/chat/completions` and `/api/agents/providers`.
- This lot was propagated on the mesh lanes without running an additional live provider smoke.
## Observation operatoire 2026-03-20 13:49 +0100
Preuves:
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first --json`
- `bash tools/cockpit/run_alignment_daily.sh --json --mesh-load-profile tower-first --no-purge`
Résultats:
- Health-check SSH: `4 OK / 0 KO`
- `mesh_sync_preflight --json --load-profile tower-first`:
- `mesh_status=degraded`
- `repo Kill_LIFE: degraded`
- `repo mascarade: degraded`
- `repo crazy_life: degraded`
- raison dominante: `cils-lockdown` + divergence locale/snapshots
- `run_alignment_daily`:
- `result=ok`
- `mesh_status=degraded`
- `mesh_load_profile=tower-first`
Note de stabilité:
- cible de charge effective: `clems@192.168.0.120`, `kxkm@kxkm-ai`, `local`, `cils@100.126.225.111`, `root@192.168.0.119` (influence charge CPU/hôte prise en compte).
## État 2026-03-20 14:15 (mémoire post lot-lb-hardening)
- Préflight mesh exécutée:
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first --json --no-log`
- `bash tools/cockpit/mesh_sync_preflight.sh --load-profile photon-safe --json --no-log`
- Observabilité:
- 4 hôtes SSH atteignables (`tools/cockpit/ssh_healthcheck.sh --json`)
- `cils` reste verrouillé par défaut pour services non critiques (`cils-lockdown`)
- Résultat opérationnel:
- `mesh_status=blocked` (dégradé applicatif: miroir local non cohérent sur `clems` pour certains repos au moment du run)
- `artifacts/cockpit/mesh_sync_preflight_20260320_140528.log` retenu comme preuve journalisée
- Actions mémoire:
- mettre à jour `docs/MESH_SYNC_INCIDENT_REGISTER_2026-03-20.md`
- confirmer / corriger le miroir `Kill_LIFE-main` sur `clems@192.168.0.120` dans la lot suivante
docs/MASCARADE_MODEL_PROFILES_KXKM_AI_2026-03-20.md
+189
View File
@@ -0,0 +1,189 @@
# Profils modeles Mascarade - kxkm-ai
Date: `2026-03-20`
Objectif: publier un catalogue de profils modeles pour `mascarade` sur `kxkm@kxkm-ai` afin de couvrir rapidement plusieurs usages sans redecider a chaque run: code, site, reflexion, recherche web, analyse, planification et mode degrade.
Source de verite:
- `specs/contracts/mascarade_model_profiles.kxkm_ai.json`
- TUI cockpit: `tools/cockpit/mascarade_models_tui.sh`
- smoke runtime: `tools/ops/operator_live_provider_smoke.py --profile <id>`
- sync runtime `kxkm-ai`: `tools/ops/sync_mascarade_agents_kxkm.sh`
## Profils publies
| Profil | Usage principal | Provider par defaut | Modele par defaut |
| --- | --- | --- | --- |
| `local-fast` | reponses tres rapides et triage local | `ollama` | `qwen3:4b` |
| `code` | implementation, debug, refactor | `ollama` | `mascarade-coder:latest` |
| `site` | web, contenu, structure produit | `ollama` | `qwen3.5:9b` |
| `reflection` | arbitrage, alternatives, risques | `ollama` | `qwen2.5:14b` |
| `web-research` | synthese externe et comparaison | `ollama` | `qwen3.5:9b` |
| `analysis` | diagnostic repo/runtime | `ollama` | `mascarade-power:latest` |
| `planning` | plans, todos, owners, validations | `ollama` | `qwen2.5:14b` |
| `fallback-safe` | mode degrade et reprise | `ollama` | `ollama:qwen3.5:9b` |
| `firmware` | firmware embarque, PlatformIO, ESP32 | `ollama` | `mascarade-platformio:latest` |
| `cad` | KiCad, FreeCAD, outillage CAD/EDA | `ollama` | `mascarade-kicad:latest` |
| `ops` | incidents, logs, runbooks, recovery | `ollama` | `mascarade-power:latest` |
| `docs` | README, specs, runbooks, syntheses | `ollama` | `qwen3.5:9b` |
| `security` | menace, hardening, abuse paths | `ollama` | `qwen2.5:14b` |
| `fine-tune` | datasets, distillation, LoRA, eval | `ollama` | `qwen3.5:9b` |
| `kill-life-firmware` | firmware cible Kill_LIFE | `ollama` | `mascarade-platformio:latest` |
| `yiacad-cad` | CAD/EDA cible YiACAD | `ollama` | `mascarade-kicad:latest` |
| `mesh-syncops` | mesh, SSH, logs, alignement | `ollama` | `mascarade-power:latest` |
| `docs-specs` | docs, specs, Mermaid, handoff | `ollama` | `qwen3.5:9b` |
## Carte d'usage
```mermaid
flowchart LR
code["Code / debug / review"] --> codep["profile: code"]
site["Site / frontend / contenu"] --> sitep["profile: site"]
reflect["Reflexion / arbitrage"] --> reflp["profile: reflection"]
research["Recherche web / sourcing"] --> webp["profile: web-research"]
analysis["Analyse repo / runtime"] --> anap["profile: analysis"]
planning["Planification / todos / coordination"] --> planp["profile: planning"]
degraded["Mode degrade / reprise"] --> fallp["profile: fallback-safe"]
fast["Latence minimale"] --> localp["profile: local-fast"]
```
## Utilisation cockpit / TUI
Lister les profils:
```bash
bash tools/cockpit/mascarade_models_tui.sh --action list
```
Afficher un profil:
```bash
bash tools/cockpit/mascarade_models_tui.sh --action show --profile analysis
```
Exporter les variables a appliquer sur `kxkm-ai`:
```bash
bash tools/cockpit/mascarade_models_tui.sh --action env --profile code
```
Recuperer le prompt systeme associe:
```bash
bash tools/cockpit/mascarade_models_tui.sh --action prompt --profile planning
```
Generer les agents dynamiques qui correspondent aux profils:
```bash
bash tools/cockpit/mascarade_models_tui.sh --action agents-json
```
## Utilisation runtime Mascarade
Le smoke runtime accepte maintenant directement un profil:
```bash
python3 tools/ops/operator_live_provider_smoke.py --profile analysis
python3 tools/ops/operator_live_provider_smoke.py --profile code
python3 tools/ops/operator_live_provider_smoke.py --profile web-research
```
Le profil selectionne:
- choisit un provider par defaut
- propose un modele par defaut et des fallbacks
- ajuste la preference de routage provider
- specialise le prompt operatoire par usage
Smoke live des agents `kxkm-*` deja seeds:
```bash
bash tools/ops/smoke_mascarade_agents_kxkm.sh --json
bash tools/ops/smoke_mascarade_agents_kxkm.sh --agents kxkm-analysis,kxkm-firmware --json
```
Le script:
- interroge l'API Mascarade live sur `kxkm-ai`
- journalise un artefact JSON local dans `artifacts/ops/mascarade_agent_smoke/`
- capture pour chaque agent le `http_status`, le `provider`, le `model`, le `content` et l'eventuelle erreur
Surface UI live:
- la page `Agents` de `mascarade-main` expose maintenant un panneau `KXKM presets for live dispatch`
- cette zone remonte les lanes critiques `kxkm-analysis`, `kxkm-firmware`, `kxkm-code`, `kxkm-cad`, `kxkm-ops`, `kxkm-fallback-safe`
- chaque preset ouvre directement le detail agent via le registre live
- le build public a ete repousse dans `api/public` via `npm run build:api-public`
## Reutilisation du chat existant sur `kxkm-ai`
Le systeme de chat Mascarade deja present sur `kxkm-ai` expose des agents dynamiques avec `preferred_provider` et `preferred_model`. La publication retenue consiste donc a convertir les profils en agents natifs `kxkm-*` plutot qu'a reconstruire une autre couche.
Planifier le seed:
```bash
bash tools/ops/sync_mascarade_agents_kxkm.sh --action plan
```
Appliquer le seed sur `kxkm-ai`:
```bash
bash tools/ops/sync_mascarade_agents_kxkm.sh --action sync --apply
```
Agents seeds:
- `kxkm-local-fast`
- `kxkm-code`
- `kxkm-site`
- `kxkm-reflection`
- `kxkm-web-research`
- `kxkm-analysis`
- `kxkm-planning`
- `kxkm-fallback-safe`
- `kxkm-firmware`
- `kxkm-cad`
- `kxkm-ops`
- `kxkm-docs`
- `kxkm-security`
- `kxkm-fine-tune`
- `kxkm-kill-life-firmware`
- `kxkm-yiacad-cad`
- `kxkm-mesh-syncops`
- `kxkm-docs-specs`
Etat applique au `2026-03-20`:
- seed ecrit sur `kxkm-ai` dans `/home/kxkm/mascarade-main/data/agents.json`
- premiere passe: 8 agents crees, 0 mis a jour
- seconde passe specialisee: 6 agents supplementaires ajoutes via le meme seed
- troisieme passe metier: 4 agents supplementaires ajoutes au meme seed
- runtime live: les `18` agents `kxkm-*` sont maintenant visibles sur `127.0.0.1:3100/api/agents`
- infrastructure locale: un runtime `mascarade-ollama-runtime` en `0.18.2` est publie sur le reseau Docker Mascarade avec le store de modeles deja present sur `kxkm-ai`
- catalogue realigne: les profils `kxkm-*` passent en `ollama-first` avec des noms de modeles compatibles (`mascarade-coder`, `mascarade-platformio`, `mascarade-kicad`, `mascarade-power`, `qwen*`)
- bridge transitoire retire du chemin actif: `kxkm-ollama-bridge.service` est desactive; la pile live continue a repondre via `mascarade-ollama-runtime` uniquement
- smoke live valide:
- `bash tools/ops/smoke_mascarade_agents_kxkm.sh --agents kxkm-analysis,kxkm-firmware,kxkm-code,kxkm-cad,kxkm-ops,kxkm-fallback-safe --json` -> `status=ok`
- `kxkm-analysis` -> `200`, `provider=ollama`, `model=mascarade-power:latest`
- `kxkm-firmware` -> `200`, `provider=ollama`, `model=mascarade-platformio:latest`
- `kxkm-code` -> `200`, `provider=ollama`, `model=mascarade-coder:latest`
- `kxkm-cad` -> `200`, `provider=ollama`, `model=mascarade-kicad:latest`
- `kxkm-ops` -> `200`, `provider=ollama`, `model=mascarade-power:latest`
- `kxkm-fallback-safe` -> `200`, `provider=ollama`, `model=qwen2.5:7b`
- artefact local consolide: `artifacts/ops/mascarade_agent_smoke/latest.json`
## Politique retenue pour kxkm-ai
- `kxkm-ai` prend la charge Mascarade polyvalente derriere `tower`.
- les profils `kxkm-*` sont maintenant orientes `ollama-first` pour rester executables localement, sans cle externe.
- les profils generaux s'appuient sur `qwen3.5:9b`, `qwen2.5:14b` et `qwen3:4b` selon la charge et la profondeur attendue.
- les profils metier utilisent les modeles locaux specialises deja presents sur la machine: `mascarade-coder`, `mascarade-platformio`, `mascarade-kicad`, `mascarade-power`.
- le mode degrade garde un chemin court `qwen2.5:7b` pour une reprise plus sure et moins couteuse.
## Suite de lot
- documenter les profils effectivement valides apres la passe `ollama-first`
- ajouter si besoin des presets plus explicites dans l'UI chat Mascarade pour choisir les agents `kxkm-*`
- etendre ensuite la meme logique de presets aux surfaces `Orchestrate` et `Playground`
docs/MASCARADE_OPS_OBSERVABILITY_FEATURE_MAP_2026-03-21.md
+89
View File
@@ -0,0 +1,89 @@
# Mascarade ops / incidents / observability feature map (2026-03-21)
## Objectif
Cartographier la couche opératoire Mascarade/Ollama désormais présente dans Kill_LIFE:
- health-check runtime
- logs TUI et logs lane opérateur
- briefs et registre d'incidents
- synthèses daily / weekly
- surfaces TUI d'accès opérateur
## Mermaid — flux opératoire
```mermaid
flowchart TD
A["mascarade_runtime_health.sh"] --> B["mascarade_logs_tui.sh"]
A --> C["render_mascarade_incident_brief.sh"]
B --> C
C --> D["mascarade_incident_registry.sh"]
A --> E["full_operator_lane.sh"]
B --> E
E --> D
C --> F["run_alignment_daily.sh"]
D --> F
F --> G["render_daily_operator_summary.sh"]
C --> H["render_weekly_refonte_summary.sh"]
D --> H
G --> H
E --> I["refonte_tui.sh"]
B --> I
```
## Modules et rôle
| Module | Rôle | Entrées | Sorties |
| --- | --- | --- | --- |
| `mascarade_runtime_health.sh` | état runtime Mascarade/Ollama | SSH `kxkm-ai`, smoke agent | JSON cockpit, `latest.json`, `latest.log` |
| `mascarade_logs_tui.sh` | lecture/analyse/purge des logs | artefacts runtime + lane opérateur | JSON cockpit, vues `summary|latest|list|purge` |
| `full_operator_lane.sh` | orchestration opérateur | API locale, health runtime, logs | JSON cockpit, hints API, snapshots logs |
| `render_mascarade_incident_brief.sh` | brief court daily | runtime latest + lane opérateur | Markdown/JSON latest |
| `mascarade_incident_registry.sh` | historique d'incidents | briefs cockpit + summaries opérateur | registre Markdown/JSON latest |
| `run_alignment_daily.sh` | routine quotidienne consolidée | health, logs, brief, registry, mesh, log_ops | log daily, JSON daily, brief/logs artifacts |
| `render_daily_operator_summary.sh` | résumé opérateur quotidien | log daily + brief + registry | Markdown/JSON latest |
| `render_weekly_refonte_summary.sh` | synthèse hebdo | logs refonte/CAD + brief + registry | Markdown hebdo |
| `refonte_tui.sh` | surface TUI cockpit | actions dédiées | accès opérateur direct |
## Carte de fonctionnalités
### P0 — Déjà en place
- health-check runtime Mascarade/Ollama
- smoke agent low-cost
- logs TUI `summary|latest|list|purge`
- snapshots post-run opérateur
- brief d'incident Markdown
- registre d'incidents horodaté
- synthèse weekly enrichie
- synthèse daily opérateur
### P1 — Prochaine montée utile
- export Markdown automatique de l'incident du jour dans la revue daily complète
- liens croisés explicites entre daily summary, brief et registry
- tri des incidents par sévérité/source
- regroupement des erreurs d'API locale par classe
### P2 — Montée en puissance
- dashboards légers ou status page dérivée des artefacts
- corrélation simple `mesh / operator lane / Mascarade runtime`
- seuils et alertes locales plus explicites
- éventuelle migration vers une brique d'observabilité plus centralisée
## Affectation agents / sous-agents
| Domaine | Agent | Sous-agent | Focus |
| --- | --- | --- | --- |
| runtime | `SyncOps` | `Runtime-Smoke` | runtime health, smoke low-cost |
| logs | `SyncOps` | `Log-Curator` | lecture, purge, latest snapshots |
| lane opérateur | `SyncOps` | `Lane-Guard` | hints API, JSON cockpit, surface native |
| briefs / handoff | `PM` | `Doc-Runbook` | briefs, registry, synthèses |
| TUI cockpit | `SyncOps` | `TUI-Ops` | raccourcis, ergonomie opérateur |
## Décision de lot
- garder la stratégie actuelle `TUI + JSON cockpit + Markdown handoff`
- éviter une dépendance observabilité lourde tant que cette couche couvre les besoins opératoires
- utiliser la veille OSS seulement comme benchmark d'évolution, pas comme migration immédiate
docs/MASCARADE_TOWER_RUNTIME_2026-03-21.md
+70
View File
@@ -0,0 +1,70 @@
# Mascarade Tower Runtime - 2026-03-21
## Etat retenu
- `tower` = `clems@192.168.0.120`
- la stack Mascarade y est deja active:
- `mascarade-api`
- `mascarade-core`
- `mascarade-ollama`
- le lot courant normalise cette machine comme premiere cible lourde du mesh Mascarade au lieu de redeployer une pile parallele.
## Profils Tower
- `tower-code`
- `tower-text`
- `tower-research`
- `tower-analysis`
Source de verite:
- `specs/contracts/mascarade_model_profiles.tower.json`
Seed distant:
- `bash tools/ops/sync_mascarade_agents_tower.sh --action sync --apply --json`
Normalisation runtime:
- `bash tools/ops/deploy_mascarade_tower_runtime.sh --action status --json`
- `bash tools/ops/deploy_mascarade_tower_runtime.sh --action apply --json`
## Politique de dispatch P2P
- charges lourdes:
- `tower -> kxkm -> local -> cils -> root-reserve`
- texte interactif / docs:
- `kxkm -> tower -> local -> cils -> root-reserve`
- `cils` reste non essentiel
- `root-reserve` reste strictement reserve
Contrat:
- `specs/contracts/mascarade_dispatch.mesh.json`
Surface CLI:
- `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`
## Diagramme
```mermaid
flowchart LR
client["Mascarade request"] --> dispatch["mascarade_dispatch_mesh.sh"]
dispatch --> heavy["heavy-code / heavy-analysis / heavy-research"]
dispatch --> text["text-production / interactive-safe"]
heavy --> tower["tower / clems@192.168.0.120"]
heavy --> kxkm["kxkm / kxkm-ai"]
text --> kxkm
text --> tower
tower --> tower_ollama["Mascarade + Ollama runtime"]
kxkm --> kxkm_ollama["Mascarade + Ollama runtime"]
```
## Decision
- `tower` porte la charge lourde par defaut.
- `kxkm` reste l'hote de chat/orchestration et le premier fallback.
- le dispatch est explicite et documente dans le repo, sans supposer un multi-endpoint natif dans Mascarade.
docs/MCP_SETUP.md
+55 -1
View File
@@ -1,6 +1,6 @@
# MCP setup
Last updated: 2026-03-14
Last updated: 2026-03-20
Source canonique pour l'usage MCP local de `Kill_LIFE`.
@@ -13,6 +13,8 @@ References canoniques:
- note de lot provenance: `docs/MCP_CAD_PROVENANCE_2026-03-14.md`
- backlog MCP KiCad: `specs/mcp_tasks.md`
- backlog cible MCP/agentics: `specs/mcp_agentics_target_backlog.md`
- surfaces GUI natives YiACAD: `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`
- hooks natifs YiACAD: `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`
## Source de verite et ownership
@@ -51,6 +53,42 @@ References canoniques:
Les micro-serveurs `kicad_kic_ai` de `mascarade` restent suivis comme surfaces auxiliaires dans `docs/MCP_SUPPORT_MATRIX.md`.
## Topologie d'exploitation (SSH / hôtes)
| Machine | Utilisateur | Priorité | Rôle | Port SSH | Port(s) service cible |
|---|---|---:|---|---:|---:|
| `clems@192.168.0.120` | `clems` | `1` | Machine opérateur, hôte de référence de travail | `22` | `22` |
| `kxkm@kxkm-ai` | `kxkm` | `2` | Mac opérateur | `22` | `22` |
| `cils@100.126.225.111` | `cils` | `3` | Mac opérateur secondaire (`photon`, locké: pas de service essentiel) | `22` | `22` |
| `root@192.168.0.119` | `root` | `4` | Serveur système / exécution système (réserve) | `22` | `22` |
Politique d’équilibrage P2P:
- Ordre par défaut: `Tower -> KXKM -> CILS -> local -> root` (réserve).
- `cils` est en verrouillage opérationnel: seul `Kill_LIFE` peut y être vérifié par défaut.
- Les préchecks non critiques sont délestés en présence de charge via `tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first`.
### Health-check SSH (script unique)
Depuis `Kill_LIFE`, exécuter:
```bash
bash tools/cockpit/ssh_healthcheck.sh
```
Prérequis: clés SSH pré-configurées pour un login sans prompt.
Options utiles:
- `--json` : format machine à machine.
- `--no-log` : exécute sans écrire dans `artifacts/cockpit`.
## Repos GitHub associés
- Core: `https://github.com/electron-rare/Kill_LIFE.git`
- Compagnon: `https://github.com/electron-rare/mascarade`
- Orchestration: `https://github.com/electron-rare/crazy-life` (repo privé)
- Références techniques: `https://github.com/electron-rare/Kill_LIFE` (source de vérité)
## Prerequis
- le repo compagnon `mascarade` existe en voisin (`../mascarade`) ou via `MASCARADE_DIR`
@@ -182,6 +220,12 @@ Ce bootstrap enregistre:
- `validate-specs`
- `knowledge-base`
- `github-dispatch`
- Les surfaces GUI YiACAD restent hors protocole MCP et s'installent via:
```bash
bash tools/cad/install_yiacad_native_gui.sh install
bash tools/cad/switch_yiacad_surfaces_to_native_forks.sh
```
- `freecad`
- `openscad`
- `huggingface`
@@ -254,3 +298,13 @@ Le chemin d'observabilite synthetique n'est pas fourni par `Kill_LIFE` seul. Si
- requalifier l'ouverture future de `A2A` une fois l'observabilite MCP homogene fermee
- garder `K-012` comme validation host-native optionnelle tant que le runtime KiCad canonique reste le conteneur; `K-014` est valide en live, avec une limite externe de quota Nexar sur le token de reference
- si un futur lot active `KiAuto`, suivre `docs/KICAD_BENCHMARK_MATRIX.md`, rester opt-in et rejouer `bash tools/tui/cad_mcp_audit.sh audit`
## Delta mesh 2026-03-20
Interpretation normative des statuts MCP dans cette refonte:
- `ready`: outil demarre et ses dependances/secrets critiques sont presents.
- `degraded`: outil demarre sans crash d'import, expose son envelope/outils, mais une dependance non critique manque.
- `blocked`: execution impossible ou securite/gate non satisfaite.
Pour `knowledge-base` et `github-dispatch`, l'absence de secrets ou de providers externes en developpement doit retomber en `degraded`, pas en echec silencieux. Cette section supersede toute mention plus ancienne qui presenterait ces surfaces comme forcement `ready` sur une machine non configuree.
docs/MESH_DIRTYSET_CLEANUP_2026-03-20.md
+41
View File
@@ -0,0 +1,41 @@
# Nettoyage des dirty-sets inter-machines
Last updated: 2026-03-20 15:45 CET
## Objectif
Aligner les dirty-sets des lanes mesh `*-main` entre `local`, `clems`, `kxkm`, `root` et `cils`, sans ecraser les worktrees historiques ni casser le `cils-lockdown`.
## Script utilise
- `bash tools/cockpit/mesh_dirtyset_sync.sh --json`
Log principal:
- `artifacts/cockpit/mesh_dirtyset_sync_20260320_152929.log`
## Actions realisees
- synchronisation des fichiers reellement dirty depuis les lanes mesh locales vers les lanes mesh distantes
- purge des artefacts Apple:
- `._*`
- `.DS_Store`
- purge des `artifacts/` transitoires dans `mascarade-main` et `crazy_life-main`
## Etat Git reel apres nettoyage
| Target | `Kill_LIFE-main` | `mascarade-main` | `crazy_life-main` |
| --- | --- | --- | --- |
| `local` | `27` | `6` | `6` |
| `clems@192.168.0.120` | `27` | `6` | `6` |
| `kxkm@kxkm-ai` | `27` | `6` | `6` |
| `root@192.168.0.119` | `27` | `6` | `6` |
| `cils@100.126.225.111` | `27` | `6` | `6` |
## Interpretation
- Les dirty-sets inter-machines sont maintenant alignes.
- Le `mesh_status=degraded` peut encore subsister:
- a cause du `cils-lockdown` volontaire pour `mascarade` et `crazy_life`,
- ou a cause du parseur/snapshot mesh qui peut doubler une entree transitoire avant l'entree `ready`.
- Ce `degraded` n'indique plus une divergence reelle des dirty-sets.
docs/MESH_SYNC_INCIDENT_REGISTER_2026-03-20.md
+62
View File
@@ -0,0 +1,62 @@
# Registre d'incidents mesh / runtime — 2026-03-20
## Convention
- `status`: `OK` / `WARN` / `KO`
- `scope`: `ssh`, `mesh-sync`, `runtime`, `repo-sync`, `logs`
- `severity`: `p0/p1/p2`
- `evidence`: path vers logs JSON/markdown
## Entrées
### 2026-03-20
- `2026-03-20T15:01:10+01:00` | `clems@192.168.0.120` | `mesh-sync` | `WARN` | `p2` | `artifacts/cockpit/machine_alignment_mesh_preflight_20260320_150014.json`
- P2P préflight exécuté avec `--load-profile tower-first`.
- Ordre calculé: `clems@192.168.0.120`, `kxkm@kxkm-ai`, `cils@100.126.225.111`, `local`, `root@192.168.0.119`.
- `cils` verrouillé par garde `cils-lockdown` pour `mascarade` et `crazy_life` (skip volontaire), ce qui maintient `mesh_status=degraded` plutôt qu’un blocage.
- `2026-03-20T15:00:14+01:00` | `clems@192.168.0.120` | `mesh-sync` | `WARN` | `p2` | `artifacts/cockpit/machine_alignment_daily_20260320_150014.log`, `artifacts/cockpit/machine_alignment_mesh_preflight_20260320_150014.json`
- `run_alignment_daily --json --mesh-load-profile tower-first --skip-healthcheck --skip-log-ops` exécuté en mode `degraded`.
- Sortie: `mesh_json_file=/Users/electron/Documents/Lelectron_rare/Kill_LIFE/artifacts/cockpit/machine_alignment_mesh_preflight_20260320_150014.json` avec `mesh_status=degraded`.
- `2026-03-20T14:55:41+01:00` | `cils@100.126.225.111` | `mesh-sync` | `WARN` | `p2` | `docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md`, `tools/cockpit/mesh_health_check.sh`, `tools/cockpit/mesh_sync_preflight.sh`
- Alignement P2P activé: ordre de charge opérationnel visé `Tower -> KXKM -> CILS -> local -> root`.
- Règle de garde: `cils` reste non-essentiel; bascule `photon-safe` recommandée en tension.
- `2026-03-20T15:58:24+01:00` | `clems@192.168.0.120` | `mesh-sync` | `WARN` | `p2` | `artifacts/cockpit/mesh_sync_preflight_20260320_*.json`
- correction en cours: durcissement parser du payload remote `snapshot_repo_remote` (normalisation CR/trim + fallback dégradé contrôlé) pour éviter les faux `blocked`.
- `run_alignment_daily` intègre désormais les résumés log_ops (`summary`) et purge pilotée (`purge`) dans la routine.
- `2026-03-20T14:32:20+01:00` | `clems@192.168.0.120` | `mesh-sync` | `WARN` | `p2` | `artifacts/cockpit/machine_alignment_mesh_preflight_20260320_143113.json`
- `mesh_sync_preflight --load-profile tower-first --json` et `--load-profile photon-safe --json` convergent sur `host_order: clems -> kxkm -> cils -> local -> root`.
- Régressions observées: `Kill_LIFE` et `crazy_life` non présents / incohérents sur `clems` (`status=blocked`), `mesh_status=blocked` attendu en mode opérateur.
- Correction déjà en place: maintien strict de la priorité Tower-first malgré charge distante.
- `2026-03-20T13:48:55+01:00` | `cils@100.126.225.111` | `mesh-sync` | `WARN` | `p1` | `artifacts/cockpit/mesh_sync_preflight_20260320_134716.log`
- précheck non-critique bloqué volontairement sur CILS (`cils-lockdown`) pour `mascarade` et `crazy_life`.
- exécution: `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first --json`
- `2026-03-20T14:06:24+01:00` | `clems@192.168.0.120` | `mesh-sync` | `WARN` | `p2` | `artifacts/cockpit/mesh_sync_preflight_20260320_140528.log`
- `mesh_sync_preflight --load-profile photon-safe --json` termine en `blocked` par divergence du miroir `Kill_LIFE` sur `clems` (répertoire non conforme git au run).
- Correction de robustesse active: sorties SSH non-conformes sont désormais passées en `degraded` sans casser le pipeline JSON.
- `2026-03-20T00:00:00+01:00` | `clems@192.168.0.120` | `ssh` | `OK`
- preuve: `artifacts/cockpit/ssh_healthcheck_<stamp>.log`
- `2026-03-20T00:00:00+01:00` | `root@192.168.0.119` | `ssh` | `OK`
- preuve: `artifacts/cockpit/ssh_healthcheck_<stamp>.log`
- `2026-03-20T00:00:00+01:00` | `kxkm@kxkm-ai` | `ssh` | `OK`
- preuve: `artifacts/cockpit/ssh_healthcheck_<stamp>.log`
- `2026-03-20T00:00:00+01:00` | `cils@100.126.225.111` | `ssh` | `OK`
- preuve: `artifacts/cockpit/ssh_healthcheck_<stamp>.log`
## Modèle d'entrée
```
YYYY-MM-DDTHH:MM:SS+TZ | <target> | <scope> | <status> | <severity> | <evidence>
```
Champ `evidence` attendu: logs JSON de `mesh_sync_preflight`, `ssh_healthcheck`, `log_ops`, `run_alignment_daily`.
docs/OPS_KILL_LIFE_ERP_BRIDGE_CONTRACT_2026-03-22.md
+126
View File
@@ -0,0 +1,126 @@
# Ops -> Kill_LIFE ERP Bridge Contract
Date: 2026-03-22
Status: baseline contract
Scope: bridge between `L'electronrare Ops`, `Kill_LIFE`, and `Mascarade`
## 1. Decision
For `Kill_LIFE`, the `ERP` layer is `L'electronrare Ops`.
Reference surface:
- [Ops — L'Electron Rare](https://www.lelectronrare.fr/ops)
Operational meaning:
- `Ops` decides priorities, manual actions, business workflow, and launch workflow
- `Kill_LIFE` executes and records continuity
- `Mascarade` assists decisions, routing, and runtime execution
## 2. Contract
The bridge is defined as:
- `Ops` provides intent and priorities
- `ERP registry` provides resource governance
- `MES` transforms priorities into executable lots
- `WMS` stores proofs, logs, artifacts, and handoffs
- `DCS` reflects the real runtime state
## 3. Mermaid — bridge flow
```mermaid
flowchart LR
OPS["ERP / L'electronrare Ops\nPriorities · manual actions · CRM · launch workflow"]
REG["ERP Registry\nMachines · roots · secret scopes · ownership"]
MES["MES / Kill_LIFE\nLots · cockpit · operator lane · daily alignment"]
WMS["WMS\nArtifacts · logs · datasets · handoffs"]
DCS["DCS\nMesh · runtimes · providers · health-checks"]
MAS["Mascarade\nDecision assistance · routing · providers"]
OPS --> REG
REG --> MES
REG --> DCS
MES --> WMS
MES --> DCS
MES --> MAS
MAS --> DCS
DCS --> WMS
WMS --> MES
```
## 4. Canonical registry
Canonical structured source:
- [ops_kill_life_erp_registry.json](/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs/contracts/ops_kill_life_erp_registry.json)
Read-only operator surface:
- [ops_erp_registry_tui.sh](/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/ops_erp_registry_tui.sh)
Supported views:
- `summary`
- `machines`
- `modules`
- `secrets`
## 5. Machine governance
Current canonical machine model:
| Label | Host | Canonical root | Role | Priority | Load policy |
|---|---|---|---|---|---|
| `tower` | `clems@192.168.0.120` | `/home/clems/mascarade` | primary-heavy | 1 | prefer-heavy |
| `kxkm` | `kxkm@kxkm-ai` | `/home/kxkm/mascarade` | interactive-ai | 2 | secondary-heavy |
| `cils` | `cils@100.126.225.111` | `/Users/cils/mascarade-main` | non-essential-burst | 3 | burst-only |
| `local` | `local` | `/Users/electron/Documents/Projets/mascarade` | control-and-fallback | 4 | fallback |
| `photon` | `root@192.168.0.119` | `/root/mascarade-main` | vm-governance-reserve | 5 | avoid-heavy |
## 6. Secret governance
Router scope:
- env var: `MISTRAL_API_KEY`
- consumer: Mascarade provider/router and Studio integrations
- source of truth: Mascarade `.env`
Governance scope:
- env var: `MISTRAL_GOVERNANCE_API_KEY`
- consumer: `Kill_LIFE` governance scripts
- source of truth: `~/.kill-life/mistral.env`
Principle:
- do not invent a second provider variable in Mascarade without an explicit consumer
- keep `Mascarade` on `MISTRAL_API_KEY`
- keep governance-only routing in `Kill_LIFE`
## 7. Dedicated agent ownership
| Layer | Owner agent | Responsibility |
|---|---|---|
| `PLM` | `PLM-Archivist` | specs, plans, contracts, maps |
| `ERP` | `Ops-Governor` | machine and secret governance |
| `MES` | `SyncOps` | lots, cockpit, operator continuity |
| `WMS` | `Artifact-Curator` | artifacts, logs, datasets, retention |
| `DCS` | `Runtime-Guard` | mesh state, runtime health, dispatch |
Additional dedicated agents:
| Agent | Responsibility |
|---|---|
| `KillLife-Bridge` | governance secrets and continuity bridge |
| `Dataset-Curator` | dataset audit and fine-tune preflight |
## 8. Immediate refactor plan
1. Close `ERP minimal`
- make the registry the visible source of truth for machine, secret, and ownership policies
2. Index `WMS`
- map artifacts to lot, layer, and consumer
3. Compact `MES`
- expose one operator entrypoint per layer
4. Clean `DCS`
- reduce machine-level ambiguity between repo root and runtime root
5. Close the loop with `Ops`
- map `/ops` priorities to executable lot categories and owners
docs/OPS_MASCARADE_KILL_LIFE_FEATURE_MAP_2026-03-21.md
+39
View File
@@ -0,0 +1,39 @@
# Carte de fonctionnalités — ops / Mascarade / kill_life (2026-03-21)
## Objectif
Rendre visible le contrat produit minimal qui doit rester cohérent entre:
- les entrées opérateur
- les surfaces Mascarade
- la mémoire de continuité `kill_life`
## Vue d'ensemble
```mermaid
flowchart LR
OPS["ops / cockpit<br/>status, lane, TUI, handoff"] --> CONTRACT["contrat produit commun<br/>status, decision, owner, artifacts,<br/>next_step, resume_ref, trust_level,<br/>routing, memory_entry"]
MASQ["Mascarade<br/>recommandation, trust, routing"] --> CONTRACT
KL["kill_life<br/>mémoire latest, reprise, handoff"] --> CONTRACT
CONTRACT --> ENTRY["points d'entrée opérateur<br/>yiacad_operator_index, refonte_tui, lot_chain"]
CONTRACT --> SURFACES["surfaces JSON / Markdown<br/>full_operator_lane, run_alignment_daily,<br/>mascarade_runtime_health, incidents, logs"]
CONTRACT --> MEMORY["artefacts de continuité<br/>kill_life_memory/latest.json|md"]
CONTRACT --> AUDIT["audit statique<br/>product_contract_audit.sh"]
```
## Carte fonctionnelle
| Couche | Rôle produit | Sortie canonique | Risque si écart |
| --- | --- | --- | --- |
| `ops` | montrer l'état réel, déclencher l'action, exposer le prochain pas | `full_operator_lane`, `run_alignment_daily`, `daily_operator_summary` | l'opérateur agit sans preuve ni point de reprise clair |
| `Mascarade` | recommander, expliciter le routing, porter le `trust_level` | `mascarade_runtime_health`, `mascarade_incidents_tui`, watch/queue/brief | recommandation opaque ou non rejouable |
| `kill_life` | persister la continuité et la reprise stable | `artifacts/cockpit/kill_life_memory/latest.json` | reprise lente ou ambiguë entre deux opérateurs |
| `entrypoints` | exposer la reprise sans navigation profonde | `yiacad_operator_index`, `refonte_tui`, `lot_chain` | rupture entre surfaces courtes et surfaces détaillées |
| `audit` | contrôler la cohérence minimale sans relancer toute la pile | `product_contract_audit/latest.json|md` | dérive silencieuse des surfaces et du contrat |
## Décision
- consolider d'abord la cohérence des surfaces existantes
- éviter d'élargir encore la surface tant que la reprise n'est pas homogène
- utiliser l'audit statique comme garde-fou léger entre deux lots
docs/OPS_MASCARADE_KILL_LIFE_PRODUCT_CONTRACT_2026-03-21.md
+75
View File
@@ -0,0 +1,75 @@
# Contrat produit `ops <-> Mascarade <-> kill_life` - 2026-03-21
## Intention
La surface produit est maintenant suffisamment large. Le bon prochain palier est de consolider la confiance et la continuité entre les trois couches:
- `ops` montre l'etat reel et declenche l'action
- `Mascarade` aide a decider sans opacite
- `kill_life` materialise la continuité d'execution
## Contrat minimal commun
Source de verite:
- `specs/contracts/ops_mascarade_kill_life.contract.json`
Champs minimaux obligatoires:
- `status`
- `decision`
- `owner`
- `artifacts`
- `next_step`
- `resume_ref`
- `trust_level`
- `routing`
- `memory_entry`
## Roles
### ops
- montre l'etat observe
- expose les preuves et artefacts
- permet le declenchement
- montre le prochain pas executable
### Mascarade
- formule une recommandation explicable
- expose la rationale
- annonce le `trust_level`
- rend visible le routing machine et les fallbacks
### kill_life
- persiste l'intention et la decision
- garde un `resume_ref` stable
- permet un handoff humain + machine sans relire tout l'historique
## Diagramme
```mermaid
flowchart LR
ops["ops\nstatus reel + action"] --> contract["contrat produit commun"]
mascarade["Mascarade\nrecommendation + trust"] --> contract
killlife["kill_life\nmemoire + reprise"] --> contract
contract --> state["status / decision / owner"]
contract --> trace["artifacts / resume_ref / next_step"]
contract --> route["routing / trust_level"]
contract --> memory["memory_entry"]
```
## Decision de lot
- on gele l'extension de surface comme priorite principale
- on aligne d'abord les sorties existantes sur ce contrat
- `tower` devient la cible lourde prioritaire pour le runtime Mascarade
- `kxkm` reste la couche interactive et le premier fallback operable
## Lots suivants
1. projeter ce contrat dans les sorties JSON cockpit prioritaires
2. faire apparaitre `trust_level`, `resume_ref` et `routing` dans les surfaces ops/Mascarade
3. raccorder l'entree `memory_entry` aux traces `kill_life`
docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md
+100
View File
@@ -0,0 +1,100 @@
# Recherche OSS — KiCad / FreeCAD / OpenSCAD pour version IA-native KILL_LIFE
Dernière mise à jour: 2026-03-20
## Critères de sélection
- Intégration IA (MCP ou APIs orientées agent).
- Licence ouverte et maintenance visible.
- Potentiel d’intégration dans un mode "host-first" (sans conteneur par défaut).
- Facilité de fork/adaptation (code Python, structure lisible, docs d’installation).
## Références candidates
### KiCad + MCP
1. [lamaalrajih/kicad-mcp](https://github.com/lamaalrajih/kicad-mcp)
- Type: MCP server pour KiCad (cross-plateforme).
- Usage envisagé: base d’API d’orchestration par agent.
- Signal d’intérêt: cible exactement KiCad + MCP.
2. [lukaalrajih/kicad-mcp-server (sur PyPI)](https://pypi.org/project/kicad-mcp-server/)
- Type: distribution orientée MCP.
- Usage envisagé: réutilisable si stabilité package souhaitée.
3. [KiCad/KiCad](https://github.com/KiCad/KiCad)
- Type: upstream officiel / miroir actif du code source KiCad.
- Usage envisagé: base de fork YiACAD et référence de suivi upstream ECAD.
### KiCad automation classique (non-MCP)
4. [INTI-CMNB/KiBot](https://github.com/INTI-CMNB/KiBot)
5. [bbernhard/KiBot](https://github.com/bbernhard/KiBot)
- Type: générateur CI/CD (Gerber/BoM/DRC/DRC etc.).
- Usage envisagé: prérequis robuste pour workflows production.
6. [productize/kicad-automation-scripts](https://github.com/productize/kicad-automation-scripts)
7. [INTI-CMNB/KiAuto](https://github.com/INTI-CMNB/KiAuto)
- Type: scripts d’automatisation KiCad.
- Usage envisagé: référence de fallback pour opérations GUI/legacy.
8. [yaqwsx/KiKit](https://github.com/yaqwsx/KiKit)
- Type: automation Python (panelization, exports).
- Usage envisagé: complément de pipeline manufacturier.
9. [MicroType-Engineering/KiBot](https://github.com/MicroType-Engineering/KiBot)
- Type: fork communautaire historique.
### FreeCAD / CAD agents
10. [ATOI-Ming/FreeCAD-MCP](https://github.com/ATOI-Ming/FreeCAD-MCP)
- Type: plugin FreeCAD avec serveur/clients MCP + GUI.
- Usage envisagé: pilote direct GUI + commandes macro.
11. [neka-nat/freecad-mcp](https://github.com/neka-nat/freecad-mcp)
- Type: serveur MCP intégré via addon FreeCAD.
- Usage envisagé: mode addon simple à brancher.
12. [jango-blockchained/mcp-freecad](https://github.com/jango-blockchained/mcp-freecad)
- Type: serveur MCP + addon multi-fournisseur.
- Usage envisagé: option multi-fournisseurs et diagnostics.
13. [contextform/freecad-mcp](https://github.com/contextform/freecad-mcp)
- Type: serveur MCP FreeCAD orienté Claude.
- Usage envisagé: piste IA-native pour pilotage commandé en lane canari.
14. [FreeCAD/FreeCAD](https://github.com/FreeCAD/FreeCAD)
- Type: upstream officiel FreeCAD.
- Usage envisagé: base de fork YiACAD et référence de suivi upstream MCAD.
### OpenSCAD / 3D text-to-geometry
15. [jhacksman/OpenSCAD-MCP-Server](https://github.com/jhacksman/OpenSCAD-MCP-Server)
- Type: MCP server de génération/reconstruction SCAD.
- Usage envisagé: terrain d’expérimentation IA-native paramétrique.
### Bibliothèques de transformation CAD utiles
16. [CadQuery/cadquery](https://github.com/CadQuery/cadquery)
- Type: API Python paramétrique moderne pour CAD scriptable.
- Usage envisagé: couche paramétrique complémentaire à FreeCAD/OpenSCAD dans YiACAD.
17. [easyw/kicadStepUpMod](https://github.com/easyw/kicadStepUpMod)
- Type: bridge KiCad ↔ FreeCAD.
- Usage envisagé: synchronisation ECAD/MCAD utile pour workflow de conversion.
## Plan de tri (proposition)
- Priorité 0: upstreams officiels (`KiCad/KiCad`, `FreeCAD/FreeCAD`) + bridge `easyw/kicadStepUpMod`.
- Priorité 1: kicad-mcp + FreeCAD-MCP (intégration directe agent).
- Priorité 2: KiBot/KiAuto/KiKit pour pipeline de production (builds, DFM, docs).
- Priorité 3: OpenSCAD MCP + CadQuery pour cas paramétriques IA-first.
## Actions proposées
1. Faire un PoC `kicad-mcp` + `lot_mcp_runtime` en mode dry-run.
2. Evaluer la compatibilité de `FreeCAD-MCP` avec les contraintes host-first macOS.
3. Stabiliser une couche `run_*_tui` commune (logs, purge, status) pour KiCad/FreeCAD/OpenSCAD.
4. Suivre `contextform/freecad-mcp` comme alternatif en parallèle (`prep` puis `smoke` de lot YiACAD).
5. Ancrer YiACAD sur `KiCad/KiCad` + `FreeCAD/FreeCAD` avec `easyw/kicadStepUpMod` comme pont ECAD/MCAD.
6. Garder `CadQuery/cadquery` comme surface paramétrique complémentaire, non bloquante.
docs/PCB_AI_FAB_INTEGRATION_MAP_2026-03-22.md
+164
View File
@@ -0,0 +1,164 @@
# PCB AI / Forge / BOM / fabrication map (2026-03-22)
## Objectif
Raccorder trois references externes a la pile existante `Forge + YiACAD + BOM + JLCPCB` sans brouiller la source de verite locale:
- [PCB Designer AI](https://pcbdesigner.ai/)
- [Quilter](https://www.quilter.ai/)
- [kicad-happy](https://github.com/aklofas/kicad-happy)
Le principe retenu reste strict:
- `Kill_LIFE` garde la source de verite locale pour `ERC/DRC`, `BOM`, `netlist`, `review`, `evidence`.
- `YiACAD` garde la couche d'execution locale `KiCad + FreeCAD`.
- `Forge` garde la couche review/dataset/fine-tune.
- Les outils externes sont integres comme accelerateurs specialises, pas comme nouvelle source de verite.
## Ancrages existants dans Kill_LIFE
La base existe deja sur quatre zones:
1. `Forge`
- `docs/plans/23_plan_integration_mistral_agents.md`
- `docs/plans/23_todo_integration_mistral_agents.md`
- `tools/cockpit/e2e_agents_test.sh`
2. `KiCad / YiACAD`
- `docs/KICAD_AI_LOCAL.md`
- `specs/kicad_mcp_scope_spec.md`
- `specs/yiacad_tux004_orchestration_spec.md`
- `tools/cad/yiacad_native_ops.py`
- `tools/cad/yiacad_backend_client.py`
3. `BOM / sourcing`
- `tools/hw/schops/schops.py`
- `tools/hw/hw_check.sh`
- `tools/cad/yiacad_backend_service.py`
- `agents/hw_schematic_agent.md`
4. `pilotage concret`
- `docs/plans/25_todo_hypnoled_pilote.md`
Conclusion: il n'y a pas de trou sur `review/BOM/preuves`. Le trou est sur `auto-placement/routing externe` et `fabrication one-click`.
## Ce que disent les sources externes
### PCB Designer AI
Constats verifies sur [pcbdesigner.ai](https://pcbdesigner.ai/):
- upload de schema, puis placement + routage par IA
- export `Gerber`, `ODB++`, formats natifs `KiCad` et `Altium`
- `BOM` avec pricing/stock live et suggestions d'alternatives
- DRC temps reel avec regles `JLCPCB`, `PCBWay` et custom
- ordering direct vers `JLCPCB`, `PCBWay`, `OSHPark`
Fit projet:
- tres fort pour une lane `prototype rapide -> package fab`
- tres bon pour `BOM + alternatives + fabrication`
- plus faible sur la maitrise IP et sur la tracabilite detaillee des decisions de layout
### Quilter
Constats verifies sur [Quilter](https://www.quilter.ai/) et [sa doc d'upload](https://docs.quilter.ai/using-quilter/upload-your-design-files):
- upload `schematic + board + project files`
- detection automatique de contraintes physiques depuis le schema
- parametrage `fabricators`, `stack-ups`, `fabrication rules`, `keepouts`, `pre-routed traces`
- revue de candidats de layout
- restitution des designs dans le meme format de fichier que l'entree, pour reouverture directe dans l'outil CAD
Inference explicite:
- je n'ai pas trouve sur source officielle la meme promesse `one-click JLCPCB` que PCB Designer AI
- en revanche, le retour dans le format CAD d'origine + les profils de fabrication rendent plausible un flux `KiCad -> Quilter -> package fab/JLCPCB` borne et controlable
Fit projet:
- meilleur candidat pour une lane `canary routing` sous garde `YiACAD`
- tres bon pour cartes complexes, contraintes physiques, fanout, validation de candidats
- moins adapte a une promesse produit `commande one-click` immediate
### kicad-happy
Constats verifies sur [GitHub - aklofas/kicad-happy](https://github.com/aklofas/kicad-happy):
- skills Claude Code pour analyser schemas, PCB, Gerbers et PDF de reference
- cycle complet `BOM -> sourcing -> pricing -> order files`
- connecteurs `DigiKey`, `Mouser`, `LCSC`
- skill `jlcpcb` pour design rules, `BOM/CPL` et workflow d'ordering
Fit projet:
- c'est la reference la plus proche de ce qu'on fait deja avec `Forge + YiACAD + HW-BOM`
- excellent comme reservoir de patterns pour `review.bom`, `sourcing`, `preparation fabrication`, `JLCPCB/LCSC`
- ne doit pas devenir une dependance runtime centrale; a traiter comme reference ouverte et source d'idees de playbooks
## Cartographie cible
| Outil | Role recommande dans Kill_LIFE | Couche principale | Owner agent | Statut recommande |
| --- | --- | --- | --- | --- |
| `PCB Designer AI` | fast lane `schema -> layout -> fab package` pour prototypes | `WMS + DCS` | `Embedded-CAD` + `HW-BOM` | `evaluate-fast-fab` |
| `Quilter` | canary `routing/placement` sous contraintes physiques | `DCS` | `CAD-Bridge` + `CAD-Smoke` | `canary-route` |
| `kicad-happy` | reference de playbooks `review/BOM/sourcing/JLCPCB` | `PLM + MES` | `HW-BOM` + `Forge` | `adopt-patterns` |
## Architecture d'integration
```mermaid
flowchart LR
SCH["KiCad schematic / board"] --> YI["YiACAD local ops\nERC DRC BOM review"]
SCH --> FORGE["Forge review / datasets / prompts"]
SCH --> QUILTER["Quilter canary routing\nphysics constraints"]
SCH --> PCBDAI["PCB Designer AI\nfast fab lane"]
FORGE --> BOM["BOM analysis / alternates"]
YI --> BOM
QUILTER --> PKG["Fab package gate\nGerber CPL BOM DRC evidence"]
PCBDAI --> PKG
BOM --> PKG
PKG --> JLC["JLCPCB / LCSC handoff"]
PKG --> ART["Kill_LIFE artifacts / proofs"]
YI --> ART
FORGE --> ART
```
## Garde-fous retenus
1. `YiACAD` reste la reference locale pour `ERC/DRC/BOM review`.
2. Aucun outil externe ne devient source de verite unique pour les artefacts de fabrication.
3. Toute lane externe doit redescendre vers un `fab package` standardise avec preuve locale.
4. `JLCPCB` reste aujourd'hui un objectif de package/handoff; le one-click n'est pas encore un workflow interne livre dans `Kill_LIFE`.
## Trous de couche a combler
1. Pas de contrat canonique `fab package` (`Gerber + CPL + BOM + DRC + provenance`).
2. Pas de lane `routing canary` pour comparer `Quilter` et la chaine locale.
3. Pas de surface `BOM sourcing + alternates + JLC/LCSC` unifiee dans `YiACAD`.
4. Pas de politique explicite `IP boundary / SaaS CAD` par projet.
## Plan de refonte recommande
### Phase 1 - Reference et cadrage
- publier une cartographie outillage et ownership
- capter les patterns `kicad-happy` dans les playbooks `Forge/HW-BOM`
- formaliser le contrat `fab package`
### Phase 2 - Canary technique
- lot `Quilter canary` sur une carte pilote `Hypnoled`
- comparaison `route candidate / contraintes / package fab`
- pas de dependance runtime globale tant que la boucle n'est pas prouvee
### Phase 3 - Fast fabrication lane
- evaluer `PCB Designer AI` comme voie `prototype rapide`
- gate obligatoire sur package de sortie avant handoff fab
- acceptance seulement si les preuves `BOM/DRC/fab package` redescendent dans `Kill_LIFE`
## Recommandation nette
- `kicad-happy` = a adopter comme reference de workflow et de prompts
- `Quilter` = a evaluer en canary de routing/placement physique
- `PCB Designer AI` = a evaluer comme lane acceleration prototype + fabrication, sous garde-fous forts
## Sources
- [PCB Designer AI](https://pcbdesigner.ai/)
- [Quilter product](https://www.quilter.ai/)
- [Quilter docs - upload your design files](https://docs.quilter.ai/using-quilter/upload-your-design-files)
- [kicad-happy GitHub](https://github.com/aklofas/kicad-happy)
docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md
+82
View File
@@ -0,0 +1,82 @@
# Provider runtime compatibility - 2026-03-20
## Purpose
This note captures the real runtime contract observed while closing the `Full operator lane` lot on `clems@192.168.0.120`.
## Runtime facts observed on 2026-03-20
- The live operator lane is now validated through `mascarade-api` with a container-safe local action runner:
- `tools/ops/operator_live_provider_smoke.js`
- The parity helper `tools/ops/operator_live_provider_smoke.py` is kept for host-side use and offline debugging.
- The validated live call on `clems` succeeded with:
- provider: `claude`
- model: `claude-sonnet-4-6`
- run id: `5ef4909f-8747-4634-a6a6-d131692787b0`
- The validated dry-run on `clems` succeeded with:
- run id: `4a9adf87-1695-4321-86a2-e066a0988533`
## Compatibility issues found
### 1. Container runtime did not have `python3`
- The original local action used `python3 tools/ops/operator_live_provider_smoke.py`.
- Inside `mascarade-api`, this failed with `spawn python3 ENOENT`.
- Decision:
- the container-executed bridge now uses `node tools/ops/operator_live_provider_smoke.js`
- the Python helper remains as a parity/debug script
### 2. The current provider stack rejects `system` as a chat message role
- `mascarade-core` logs showed repeated failures with:
- `messages: Unexpected role "system". The Messages API accepts a top-level system parameter`
- Decision:
- the smoke payload now sends `system` as a top-level field
- `messages` now start at the user turn
### 3. Explicit provider/model forcing was not the stable path today
- Explicit `openai:*` forcing was not reproducibly stable during this lot.
- The runtime succeeded when the chat request let the server choose its default model.
- Decision:
- the smoke leaves `model` unset unless an explicit operator override is requested
- provider/model are inferred from the actual response body when present
## Adoption policy for the operator lane
- Default mode:
- do not force `model`
- let the runtime choose the currently healthy default model
- Explicit override mode:
- keep `--provider` and `--model` available for diagnostics
- send `model` only when the operator explicitly requests it
- surface failures as `degraded` instead of crashing the workflow
- Operator proof:
- evidence stays in `artifacts/operator_lane/live_provider_result.json`
- the runbook remains `bash tools/cockpit/full_operator_lane.sh [dry-run|live|all]`
## T-OL-005 closure note
- The operator smoke runners no longer inject a `model` automatically from provider/profile selection.
- The runtime default path remains the canonical path.
- Explicit `--model` stays available for diagnostics only.
## Official web research used
### Anthropic
- Anthropic documents that the Messages API uses a top-level `system` parameter rather than a `system` role in `messages`:
- https://docs.anthropic.com/de/api/migrating-from-text-completions-to-messages
- Anthropic also documents that OpenAI SDK compatibility hoists `system` / `developer` messages and is not the preferred production path:
- https://docs.anthropic.com/en/api/openai-sdk
### OpenAI
- OpenAI still documents Chat Completions as an available API surface and explicitly discusses `system` and `user` messages in compatibility guidance:
- https://developers.openai.com/api/reference/overview
## Follow-up tasks
- Restore `mesh_sync_preflight` visibility for the staged `Kill_LIFE-main` and `crazy_life-main` lanes on `clems`.
- Propagate the runtime-normalized operator lane patchset to the remaining mesh lanes without overwriting non-mesh worktrees.
- Reintroduce explicit provider/model probes only after the runtime default path remains stable over several passes.
docs/QUICKSTART.md
+23
View File
@@ -81,6 +81,23 @@ tools/hw/cad_stack.sh pio system info
Le workspace monté est `Kill_LIFE` par défaut.
### 6bis. Surfaces YiACAD natives
Pour installer puis utiliser les surfaces natives KiCad et FreeCAD:
```bash
bash tools/cad/install_yiacad_native_gui.sh install
bash tools/cad/switch_yiacad_surfaces_to_native_forks.sh
bash tools/cockpit/yiacad_uiux_tui.sh --action status
```
Documentation utile:
- `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`
- `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- `docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`
Les wrappers locaux qui lancent des runtimes Python/Node ou des conteneurs remappés utilisent un `HOME` explicite local au repo. La règle est documentée dans [RUNTIME_HOME.md](RUNTIME_HOME.md).
---
@@ -96,3 +113,9 @@ Les wrappers locaux qui lancent des runtimes Python/Node ou des conteneurs remap
Pour toute question, consulte la FAQ ou ouvre une issue !
Pour toute question, consulte la FAQ ou ouvre une issue !
## 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.
docs/REFACTOR_MANIFEST_2026-03-20.md
+213
View File
@@ -0,0 +1,213 @@
# Refonte complète - Manifeste opérateur (2026-03-20)
## Périmètre
Ce manifeste formalise la phase de refonte exhaustive de `Kill_LIFE` :
- Audit technique de bout en bout.
- Intégration de l’intelligence (LLM + orchestrateurs + MCP) de manière optionnelle et contrôlée.
- Alignement des `README`, des plans (`docs/plans/*`) et des specs (`specs/*`).
- Gouvernance multi-agent/sous-agent pour réduire la dérive.
- Scripts TUI pour exécuter les lots, suivre la dette et manipuler les logs.
## États observés (2026-03-20)
- Arborescence déjà structurée (firmware, hardware, tools, docs, specs, compliance).
- Présence d’un socle doc/plan mature, mais certaines sections demeurent placeholder.
- Outils d’enchainement automatique déjà existants (`tools/cockpit`, `tools/autonomous_next_lots.py`), mais peu d’interface opérationnelle unifiée.
- Sources de logs existantes dans `artifacts/*`, mais pas de boucle TUI dédiée à la refonte.
- Intégration IA déjà présente : ZeroClaw, n8n, LangGraph, AutoGen, MCP.
## Diagramme cible global (architecture refonte)
```mermaid
flowchart TD
Intake[00_intake.md] --> Spec[01_spec.md]
Spec --> Arch[02_arch.md]
Arch --> Plan03[specs/03_plan.md]
Arch --> Tasks04[specs/04_tasks.md]
Plan03 --> Docs[docs/plans/*]
Plan03 --> AIMap[docs/AGENTIC_LANDSCAPE.md]
Tasks04 --> Cockpit[tools/cockpit/refonte_tui.sh]
Cockpit --> Logs[artifacts/refonte_tui/*.log]
Logs --> Audit[docs/REPO_DEEP_ANALYSIS_2026-03-11.md]
Audit --> Execute[actions]
Tools[tools/*] --> Execute
MCP[MCP runtime] --> Tools
IA[AI intégrée] --> Execute
```
## Analyse d’intégration IA
| Surface | Opportunité | Bénéfice attendu | Risque | Proposition |
| --- | --- | --- | --- | --- |
| Specs + Plans | Triage + résumé de lot par lot | Réduction des erreurs de contexte et du temps de cadrage | Hallucinations, dérive de scope | Conserver `specs/constraints.yaml` comme source autoritaire et ne valider qu’avec sorties structurées (checklist + diff) |
| MCP Runtime | Orchestration de santé et de smoke | Homogénéité des contrôles locaux + CI | Latence des serveurs externes | Garde-fou : tout appel réseau signé ou explicitement autorisé |
| Firmware / Hardware | Analyses de cohérence automatique + génération d’aide à la review | Gains de répétabilité, preuve de conformité | Génération de suggestions non applicables | Mode "propose only" + mode apply par lot humain |
| CAD / KiCad + FreeCAD | Fusion IA-native par lot pour prototypage ECAD/MCAD | Réduction du temps de setup + surface commune de pilotage | Divergence fork, scripts non reproductibles | YiACAD par `tools/cad/yiacad_fusion_lot.sh`, avec preflight + statut + logs dédiés |
| UI/UX shell | Refonte Apple-native 2026 des surfaces opérateur et CAD | Navigation plus lisible, densité maîtrisée, adoption macOS cohérente | Effet cosmétique sans gain métier, surcouche incohérente avec les forks | Shell unifié `sidebar -> canvas -> inspector`, commandes IA contextualisées, TUI dédiée et artefacts auditables |
| Docs / Evidence | Rédaction de cartes et rapports d’écart | Réduction de la dette documentaire | Surcharge de fausses alertes | Checklist de sortie avec seuil de bruit et filtre |
| Logs / Incident ops | Consolidation, corrélation, purge | Traçabilité des lots et reprise rapide | Conservation trop longue, bruit | Politique de rétention explicite (`--days`, purge contrôlée) |
## Tableau des intégrations IA proposées (alignées sur le manifeste)
- [x] Activer la couche IA comme surface d’accélération, jamais comme autorité.
- [x] Prioriser l’intégration par “overlay” (optionnelle, activable), pas en hard-dependency.
- [x] Encadrer chaque automation par des labels `ai:*` et gates existants.
- [ ] Expérimenter un pilote AutoGen/CrewAI sur un lot non critique (documentation + reporting uniquement).
- [ ] Mettre en place une matrice d’usage IA par surface (`docs/AI_WORKFLOWS.md` mis à jour).
- [x] Ajouter un lot de fusion CAD `yiacad-fusion` au lot-chain avec rollback explicite.
- [ ] Créer un référentiel de prompts/bridges réutilisables pour tests et audits.
## Cartographie fonctionnelle (mermaid)
```mermaid
flowchart LR
A[docs/plans] -->|pilotent| B[specs]
B --> C[tools]
C --> D[runtime]
D --> E[evidence]
B --> F[agents]
F --> G[decisions + approvals]
G --> H[docs]
H --> I[CI/GitHub dispatch]
J[Logs] -->|analyse| B
K[TUI cockpit] -->|run/clean/analyze| J
```
## Plan de lots et priorités
### P0 (blocage potentiel)
- [x] Stabiliser la matrice agent/sous-agent.
- [x] Supprimer les points de confusion docs/specs dans `README`, `docs/index`, `specs/*`.
- [x] Rendre exécutables : audit de cohérence + run de lot + journalisation.
### P1 (qualité + fiabilité)
- [x] Mettre à jour la feature map et les cartes mermaid canoniques.
- [x] Documenter la stratégie logs (lecture, analyse, purge) dans le manifeste.
- [x] Actualiser le plan de web research OSS et le score de similarité projet.
- [x] Compléter le lot `yiacad-fusion` (prepare, smoke, status, logs, clean-logs) côté scripts/docs/planification.
- [x] Publier l’audit UI/UX Apple-native et la carte fonctionnelle dédiée YiACAD.
### P2 (accélération future)
- [ ] Créer une extension d’assistant IA par lot (pilotable, dry-run).
- [x] Construire une synthèse hebdomadaire automatique de l’avancement.
- [ ] Industrialiser la preuve YiACAD (`artifacts/cad-fusion`) dans la fenêtre de pilotage locale.
- [ ] Injecter les patterns Apple-native directement dans les surfaces compilées des forks KiCad/FreeCAD.
## Référence des agents et sous-agents (exécution)
| Agent principal | Sous-agents | Missions | Compétences-clés |
| --- | --- | --- | --- |
| PM | PM-Plan, PM-Coord | Consolidation de backlog, priorisation, jalons, validation de faisabilité | specs, labels, gates, communication |
| Architect | Arch-Design, Arch-Decision | Schéma d’architecture refonte, ADR, cohérence interfaces | `docs`, `specs`, MCP, intégration système |
| CAD | CAD-Fusion, CAD-Smoke | Orchestration KiCad/FreeCAD, vérification smoke, gestion de rollback | kicad/mcp, freecad/mcp, scripts de statut |
| Firmware | FW-Unit, FW-Build, FW-Evidence | Plans d’implémentation, audit firmware, quality gates | PlatformIO, tests, snapshots d’evidence |
| HW Schematic | HW-Bulk, HW-BOM | Cohérence schématique, flux CAD/MCP, preuves de contrôle | kicad-tools, schops, exports, validation ERC/DRC |
| QA | QA-Tests, QA-Suite, QA-Compliance | Regression matrix, scripts, rapport de couverture, drift logs | CI, route parity, test plan |
| Doc | Doc-Refacto, Doc-Runbook | Unification manifeste, maintenance README/plans, matrice web docs | mermaid, plans, opérabilité |
## Scripts opérationnels (TUI et artefacts)
- `tools/cockpit/refonte_tui.sh` : cockpit TUI de refonte
- audit de cohérence
- exécution de lot auto
- checks MCP
- lecture logs
- suppression contrôlée de logs
- `tools/cad/yiacad_fusion_lot.sh` : lot IA-native KiCad + FreeCAD (prepare/smoke/status/logs/clean-logs)
- logs dédiés dans `artifacts/cad-fusion`
- `tools/cockpit/render_weekly_refonte_summary.sh` : synthèse markdown lots/logs/état machine
- sortie canonique: `artifacts/cockpit/weekly_refonte_summary.md`
- `tools/cockpit/lot_chain.sh` + `tools/cockpit/run_next_lots_autonomously.sh` : maintien de la chaîne automatisée
- `tools/doc/readme_repo_coherence.sh` : audit README/proofs
- `tools/autonomous_next_lots.py` : lot detection et planification
Chaque commande est historisée dans `artifacts/refonte_tui/`.
## Cartes de fonctionnalités générées
- `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- `docs/YIACAD_APPLE_UI_UX_FEATURE_MAP_2026-03-20.md`
- `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
- `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- `docs/AGENTIC_LANDSCAPE.md`
- `docs/REFACTOR_MANIFEST_2026-03-20.md`
- `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- `specs/yiacad_uiux_apple_native_spec.md`
## Web research OSS (approuvée et intégrée)
- `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
- `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`
## Bilan d’alignement machine/lot (2026-03-20 11:08)
- `ssh_healthcheck.sh --json` : OK sur les 4 machines opérationnelles.
- `run_alignment_daily.sh` : OK en local et en mode `--skip-healthcheck --json` sur cibles.
- `mesh_sync_preflight --json` : `mesh_status=degraded` (attendu tant que `cils-lockdown` reste actif en mode tower-first), pas de blocage immédiat de lot tant que la gouvernance de sécurité reste en place.
- Écart prioritaire ouvert: divergence `mascarade` entre `root` (branche `feat/apple-coreml-runtime-lot`) et cible `kxkm` (clone `mascarade` non exploitable).
- Recommandation: conserver `lots controles` jusqu’à réconciliation du contrat `mascarade`.
### Bilan d’exécution enchaînée (2026-03-20 11:08)
- `bash tools/doc/readme_repo_coherence.sh audit` : exécution OK (aucun drift bloquant actif).
- `bash tools/cockpit/log_ops.sh --action summary --json` : `status=done`, `count=66`, `stale=0`.
- `bash tools/cockpit/refonte_tui.sh --action log-ops --verbose` : `status=done`, `count=66`, `stale=0`.
- Logs inspectés pour cette passe: `artifacts/cockpit/*` et `artifacts/refonte_tui/*`.
### Priorités immédiates (2026-03-20)
- [x] Réconcilier la topologie `mascarade` (branche cible + clone sur `kxkm`) et clore `T-MESH-005`.
- [ ] Stabiliser le lot `T-RE-204` (`zeroclaw-integrations`) avec preuve de lot chain propre.
- [x] Réconcilier `T-MESH-006` (handshake `crazy_life`) après preuve d’adoption contrat.
- [ ] Exécuter une purge contrôlée `--days 14` puis `--days 7` avec conservation des artefacts utiles.
- [ ] Rejouer la preuve live YiACAD (`prepare`, `status`, puis `smoke`) après stabilisation `cad-mcp-host`.
### Plan de progression récentes (2026-03-20)
- [x] Corriger `README.md` (liens relatifs + compteur `specs/` aligné).
- [x] Ajouter des cartes Mermaid de contrôle refonte.
- [x] Actualiser la stratégie de déploiement IA native pour CAD (KiCad/FreeCAD) dans `tools/cad/ai_native_forks.sh`.
## Mémoire de lot (mise à jour prévue)
- Ajouter une entrée `manifest_date: 2026-03-20` dans le plan opératoire courant.
- Réaligner `docs/plans/12_plan_gestion_des_agents.md` et `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md` avec ce manifeste.
- Fermer les tâches `K-DA-*` correspondantes dès validation des scripts et docs.
## Delta mesh tri-repo 2026-03-20
Le manifeste est etendu a un mode tri-repo maillé.
- Canonique: aucun depot unique, gouvernance egalitaire versionnee.
- IA: coeur d'orchestration, pas simple overlay documentaire.
- Execution: chaque lot declare son `write_set` et repasse par preflight si le contexte bouge.
- Propagation: `sync continue` par defaut, `lots controles` si convergence incertaine.
- Validation: README/docs, preflight SSH/repos, contrats MCP, evidence packs.
## Carte de gouvernance IA-native (Mermaid)
```mermaid
flowchart LR
Fork[AI-native Repos] --> KiCadFork[kicad-ki (branch kill-life-ai-native)]
Fork --> FreeCADFork[freecad-ki (branch kill-life-ai-native)]
KiCadFork --> CADMCP[run_freecad_mcp + run_kicad_mcp]
FreeCADFork --> CADMCP
CADMCP --> MCPOverlay[Kill_LIFE tools/mcp_*]
MCPOverlay --> RefonteTUI[tools/cockpit/refonte_tui.sh]
RefonteTUI --> Evidence[artifacts/refonte_tui + docs/*]
Evidence --> Replan[specs/03_plan.md / specs/04_tasks.md]
```
```mermaid
flowchart TD
Plan[Plan d'action] --> Prep[Preflight mesh + SSH]
Prep --> Lot[Choix lot (owner_repo / owner_agent / write_set)]
Lot --> Validate[Validation: validate_specs + readme coherence + logs]
Validate --> Sync[Sync targets (local + remotes)]
Sync --> Evidence
Evidence --> Report[Question opérateur / prochain lot]
Report --> Plan
```
docs/REPO_STATE.md
+5 -5
View File
@@ -1,11 +1,11 @@
<!-- REPO_STATE:v1 -->
Repo: Kill_LIFE
Branch: main
HEAD: 225f2f856eb11da28ea1aad4cea1d35244388fca
HeadDate: 2026-03-15T00:00:00+01:00
HeadSubject: Baseline capture before multi-repo implementation lots
HEAD: bd3f7b99154f86057ba18b9948d940df55722b12
HeadDate: 2026-03-15T21:56:51+01:00
HeadSubject: feat(tools): align mcp runtime status and cad tooling
RepoURL: https://github.com/electron-rare/Kill_LIFE.git
ProjectKind: agentic_orchestrator
PivotChanges: [{"path": "(none)", "tags": ["general_change"]}]
PivotChanges: [{"path": "tools/cad_runtime.py", "tags": ["general_change"]}, {"path": "tools/freecad_mcp.py", "tags": ["general_change"]}, {"path": "tools/mcp_runtime_status.py", "tags": ["general_change"]}, {"path": "tools/tui/cad_mcp_audit.sh", "tags": ["general_change"]}, {"path": "tools/tui/kicad_benchmark_review.sh", "tags": ["general_change"]}]
ImpactGates: general_change
GeneratedAtUTC: 2026-03-15T00:00:00Z
GeneratedAtUTC: 2026-03-21T19:45:12Z
docs/REPO_STATE_HEADER_CONTRACT.md
+4 -5
View File
@@ -4,7 +4,7 @@ Version: `v1`
## Source of truth
The global response header MUST be derived only from each repository file:
The global response header MUST be derived only from each configured repository file:
- `docs/REPO_STATE.md`
@@ -17,14 +17,13 @@ No free-form manual edits are allowed in generated outputs.
- `tools/repo_state/lint_header_contract.py`
- `docs/REPO_STATE.md`
- `docs/repo_state.json`
- `tools/repo_state/repo_refresh.sh` (targets default: Kill_LIFE)
## Header format (mandatory)
```md
[REPO-STATE UTC: <timestamp>]
Kill_LIFE | HEAD <sha> | pivots: <...> | gates: <...>
RTC_BL_PHONE | HEAD <sha> | pivots: <...> | gates: <...>
le-mystere-professeur-zacus | HEAD <sha> | pivots: <...> | gates: <...>
[/REPO-STATE]
```
@@ -35,7 +34,7 @@ le-mystere-professeur-zacus | HEAD <sha> | pivots: <...> | gates: <...>
- missing `<!-- REPO_STATE:v1 -->` marker in `docs/REPO_STATE.md`
- missing required keys in `docs/REPO_STATE.md` or `docs/repo_state.json`
- malformed header markers in `artifacts/repo_state/header.latest.md`
- missing one of the 3 repository lines in the generated header
- missing the repository line in the generated header
## Commands
@@ -45,7 +44,7 @@ Generate local state:
python tools/repo_state/collect.py --repo-name Kill_LIFE
```
Generate global artifacts from sibling repos:
Generate global artifacts:
```bash
tools/repo_state/repo_refresh.sh
docs/RUNBOOK.md
+26
View File
@@ -5,6 +5,8 @@
- Carte fonctionnelle canonique : `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- Séquence locale : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
- Séquence GitHub : `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- Audit UI/UX YiACAD : `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- Points d’insertion natifs YiACAD : `docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`
Choix opératoire rapide :
- validation et exécution locale avant CI distante : séquence `workflow local`
@@ -114,3 +116,27 @@ Lecture utile :
## 5) Workflows métiers
Voir `docs/workflows/README.md`.
## 6) YiACAD UI/UX lane
Surfaces opératoires recommandées:
```bash
bash tools/cockpit/yiacad_uiux_tui.sh --action status
bash tools/cockpit/yiacad_uiux_tui.sh --action agent-matrix
bash tools/cockpit/yiacad_uiux_tui.sh --action insertion-points
bash tools/cockpit/yiacad_uiux_tui.sh --action logs-summary
```
Points d’appui:
- `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`
- `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_FEATURE_MAP_2026-03-20.md`
- `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`
## 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.
docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md
+230
View File
@@ -0,0 +1,230 @@
# Contrat Mesh Tri-Repo 2026-03-20
Statut: actif
Version: `mesh-contract/v1`
Date: `2026-03-20`
Portee: `Kill_LIFE`, `mascarade`, `crazy_life`, machines SSH associees
Ce document formalise la gouvernance maillée du programme tri-repo. En cas de conflit avec une documentation plus ancienne, ce contrat fait foi pour les surfaces suivantes: ownership, execution lots, sync preflight, handoff agentique, statuts MCP, snapshots machines/repos et workflow handshake inter-repos.
## Principes directeurs
- Aucun depot n'est la source de verite absolue.
- Chaque lot declare un `owner_repo`, un `owner_agent`, un `write_set`, des `validations`, des `evidence` et des `sync_targets`.
- Nous ne sommes pas seuls dans le codebase: aucun revert de changements externes, aucun merge implicite hors `write_set`.
- Toute divergence de `branch`, `sha`, `remote`, `dirty-set` ou ownership fait retrograder la propagation en `lots controles`.
- Les surfaces IA sont coeur d'orchestration, mais toute action destructive, distante ou dependante de secrets reste derriere des gates explicites.
## Roles par repo
| Repo | Mission primaire | Exemples de surfaces |
| --- | --- | --- |
| `Kill_LIFE` | embarque, evidence, orchestration locale, launchers, smokes | TUI cockpit, repo-state, scripts MCP locaux, preuves d'execution |
| `mascarade` | runtime agentique, providers, observabilite compagnon, integrations | runtime IA, adapters MCP, dispatchs applicatifs, pipelines compagnon |
| `crazy_life` | cockpit operateur, edition de workflows, supervision web/devops | UI web, workflow editor, dashboards, supervision humaine |
## Regle d'execution d'un lot
Un lot valide doit exposer les champs suivants:
```yaml
lot_id: mesh-governance
owner_repo: Kill_LIFE
owner_agent: PM-Mesh
write_set:
- docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md
- tools/cockpit/mesh_sync_preflight.sh
preflight:
- bash tools/cockpit/mesh_sync_preflight.sh --json
- bash tools/cockpit/ssh_healthcheck.sh --json
validations:
- bash tools/run_autonomous_next_lots.sh status
- bash tools/specs/sync_spec_mirror.sh all --yes
- bash tools/test_python.sh --venv-dir .venv --suite stable
sync_targets:
- local
- clems@192.168.0.120
- root@192.168.0.119
- kxkm@kxkm-ai
- cils@100.126.225.111
load_profile:
default: tower-first
options: [tower-first, photon-safe]
load_aware: true
overload_threshold: 1.8
non_critical_skip: overload_or_cils_lockdown
photon_safe_behavior: cils excluded from all non-SSH checks
reserve_host: root@192.168.0.119
critical_hosts:
tower: clems@192.168.0.120
secondary_kxkm: kxkm@kxkm-ai
secondary_cils: cils@100.126.225.111
local: local
reserve_root: root@192.168.0.119
critical_repo: Kill_LIFE
host_priority_order: [clems@192.168.0.120, kxkm@kxkm-ai, cils@100.126.225.111, local, root@192.168.0.119]
critical_repos: [Kill_LIFE]
evidence:
- artifacts/cockpit/useful_lots_status.md
- docs/MACHINE_SYNC_STATUS_2026-03-20.md
```
## Overlay agents / sous-agents
Les huit agents principaux et leurs sous-agents standards sont:
| Agent | Perimetre principal | Sous-agents types |
| --- | --- | --- |
| `PM-Mesh` | backlog tri-repo, arbitrage, priorisation, sequence de propagation | `Lot-Planner`, `Risk-Triager` |
| `Arch-Mesh` | contrats, ADR, versionnement interfaces | `Schema-Guard`, `Compat-Auditor` |
| `Embedded-CAD` | firmware, hardware, CAD/MCP locaux | `Firmware-Lane`, `CAD-Lane` |
| `Runtime-Companion` | runtime IA, providers, compat MCP | `Provider-Bridge`, `Runtime-Smoke` |
| `Web-Cockpit` | UI, workflow editor, supervision | `UI-Flow`, `Schema-Consumer` |
| `QA-Compliance` | matrices, evidence, gates | `Spec-Mirror`, `Evidence-Pack` |
| `Docs-Research` | README, specs, Mermaid, veille OSS | `Mermaid-Map`, `OSS-Benchmark` |
| `SyncOps` | SSH, repo-state, logs, sync continue | `SSH-Health`, `Log-Ops` |
## Mermaid: topologie tri-repo
```mermaid
flowchart LR
KL[Kill_LIFE\nlocal orchestration\nembedded evidence] <-- contract --> MA[mascarade\nagent runtime\nproviders]
MA <-- contract --> CL[crazy_life\nweb cockpit\nworkflow editor]
KL <-- workflow/schema handshake --> CL
KL <-- MCP/runtime handshake --> MA
KL --> SSH1[clems@192.168.0.120]
KL --> SSH2[kxkm@kxkm-ai]
KL --> SSH3[cils@100.126.225.111]
KL --> SSH4[root@192.168.0.119]
```
```mermaid
flowchart LR
classDef tier1 fill:#14355f,color:#fff
classDef tier2 fill:#2f5f9f,color:#fff
classDef tier3 fill:#3f8fbf,color:#fff
classDef tier4 fill:#7fb5de
classDef tier5 fill:#b0c4de
T1[clems@192.168.0.120\\nPriority 1\\nPriority rank: 1]:::tier1 --> T2[kxkm@kxkm-ai\\nPriority 2\\nPriority rank: 2]:::tier2
T2 --> T3[cils@100.126.225.111\\nPriority 3\\ncritical-only in tower-first\\nPriority rank: 3]:::tier3
T3 --> T4[local\\nPriority 4\\nPriority rank: 4]:::tier4
T4 --> T5[root@192.168.0.119\\nPriority 5\\nReserve fallback]:::tier5
```
## Mermaid: execution d'un lot en codebase partage
```mermaid
flowchart TD
A[Select lot] --> B[Declare owner_repo + owner_agent + write_set]
B --> C[Run mesh preflight]
C --> D{Converged?}
D -- yes --> E[Edit within declared write_set]
D -- no --> F[Downgrade to controlled lot]
F --> G[Refresh snapshot and replan]
E --> H[Run validations]
H --> I[Publish evidence + sync targets]
I --> J[Update plans/todos/docs]
```
## Mermaid: flux TUI et logs
```mermaid
flowchart LR
TUI[refonte_tui] --> PRE[mesh_sync_preflight]
TUI --> SSH[ssh_healthcheck]
TUI --> LOG[log_ops]
PRE --> ART[artifacts/cockpit]
SSH --> ART
LOG --> ART
ART --> DOCS[docs/MACHINE_SYNC_STATUS + plans]
```
## Contrats publics normalises
### Statut MCP
Valeurs autorisees:
- `ready`: outils exposes et dependances/credentials disponibles.
- `degraded`: outil demarre sans crash silencieux, expose ses outils ou son envelope, mais une dependance non critique manque.
- `blocked`: l'outil ne peut pas etre utilise ou la securite/contrat empêche l'execution.
### Handoff agentique
```json
{
"lot_id": "mesh-governance",
"owner_repo": "Kill_LIFE",
"owner_agent": "PM-Mesh",
"write_set": ["docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md"],
"preflight": ["bash tools/cockpit/mesh_sync_preflight.sh --json"],
"validations": ["bash tools/run_autonomous_next_lots.sh status"],
"evidence": ["artifacts/cockpit/useful_lots_status.md"],
"sync_targets": ["local", "clems@192.168.0.120"]
}
```
### Snapshot machine/repo
```json
{
"machine": "clems@192.168.0.120",
"repo": "Kill_LIFE",
"branch": "main",
"sha": "bd3f7b99154f86057ba18b9948d940df55722b12",
"remote": "https://github.com/electron-rare/Kill_LIFE.git",
"dirty_set": ["docs/REPO_STATE.md", "docs/repo_state.json"],
"required_script": "tools/repo_state/repo_refresh.sh",
"ssh_health": "ok"
}
```
### Workflow schema handshake `Kill_LIFE <-> crazy_life`
- Le schema de workflow est versionne et publie comme artefact contractuel.
- `Kill_LIFE` fournit les smokes et la preuve de compatibilite machine/repo.
- `crazy_life` consomme le schema sans supposer des champs implicites.
- Toute rupture retrocompatible doit:
- incrementer la version,
- mettre a jour le mapping UI,
- ajouter une preuve de validation dans le lot.
## Artefacts machine-readables
Contrats publies dans le repo:
- `specs/contracts/agent_handoff.schema.json`
- `specs/contracts/repo_snapshot.schema.json`
- `specs/contracts/workflow_handshake.schema.json`
Exemples de reference:
- `specs/contracts/examples/agent_handoff.mesh.json`
- `specs/contracts/examples/repo_snapshot.mesh.json`
- `specs/contracts/examples/workflow_handshake.mesh.json`
Checker local sans dependance externe:
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/agent_handoff.schema.json --instance specs/contracts/examples/agent_handoff.mesh.json`
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/repo_snapshot.schema.json --instance specs/contracts/examples/repo_snapshot.mesh.json`
- `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/workflow_handshake.schema.json --instance specs/contracts/examples/workflow_handshake.mesh.json`
## Politique de propagation
- Mode nominal: `sync continue`.
- Downgrade automatique en `lots controles` si divergence de convergence, conflit de ownership ou dirty-set non maitrise.
- Une convergence n'est consideree acquise qu'apres preflight machine + evidence locale.
## Evidence minimale par lot
- `artifacts/cockpit/useful_lots_status.md`
- sortie JSON des preflights TUI
- doc ou spec mise a jour
- todo/plan du lot mis a jour
## Criteres de validation
- README et docs alignes sur l'etat reel.
- TUI disponible pour preflight, SSH health et log ops.
- MCP sans crash d'import: `ready` ou `degraded`, jamais `blocked` sans justification.
- Divergences machines detectees avant propagation.
docs/WEB_RESEARCH_AGENTIC_STACK_2026-03-20.md
+35
View File
@@ -0,0 +1,35 @@
# Veille officielle agentic stack / tri-repo
Last updated: 2026-03-20 15:45 CET
Sources officielles verifiees le 2026-03-20.
| Projet | Source officielle | Apport utile pour le tri-repo | Decision actuelle |
| --- | --- | --- | --- |
| MCP | https://modelcontextprotocol.io/docs/getting-started/intro | Contrat standard pour outils, sources de donnees et workflows relies aux agents | A conserver comme colonne vertebrale des bridges outil/runtime |
| OpenAI Agents SDK | https://openai.github.io/openai-agents-python/ | Primitives `agents`, `handoffs`, `guardrails`, `sessions`, tracing et MCP integre | A utiliser comme reference de design pour la gouvernance agentique et les handoffs |
| AutoGen | https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/tutorial/index.html | Teams, AgentChat, GraphFlow, runtime event-driven | A benchmarker pour orchestration multi-agent plus riche, sans remplacement direct |
| LangGraph | https://docs.langchain.com/oss/python/langgraph/overview | Graphes et orchestration stateful pour workflows complexes | A reutiliser comme reference de design pour `graph engine` / workflow handshakes |
| OpenHands | https://docs.openhands.dev/openhands/usage/cli/quick-start | Terminal mode, headless mode, MCP servers, IDE integration | Bon benchmark pour execution agentique outillee, pas source de verite runtime |
| n8n | https://docs.n8n.io/ | Orchestration workflow visuelle, webhooks, executions, integrations | A conserver pour les lanes d'integration et les smokes workflow |
| Wokwi CI | https://docs.wokwi.com/wokwi-ci/getting-started | Simulation embarquee CI, utile pour hardware/firmware sans cible physique | A evaluer pour la partie ZeroClaw / embedded CI |
| PlatformIO Unit Testing | https://docs.platformio.org/en/latest/advanced/unit-testing/index.html | Cadre de tests embarques, segmentation par environnements, unit testing cible | A garder comme reference pour QA embarquee et preuve firmware |
## Notes d'integration
- MCP reste le contrat d'interface le plus naturel pour `Kill_LIFE <-> mascarade <-> crazy_life`.
- L'OpenAI Agents SDK fournit la meilleure reference officielle pour la separation `agent`, `handoff`, `guardrail`, `session`, `trace`.
- AutoGen et LangGraph sont les deux benchmarks les plus utiles pour les futurs lots d'orchestration avancee:
- AutoGen pour les teams / runtimes plus riches.
- LangGraph pour les graphes stateful et les transitions explicites.
- OpenHands est surtout un benchmark de posture operateur et d'integration CLI/MCP.
- n8n, Wokwi CI et PlatformIO sont a conserver comme piliers de workflow, simulation et validation technique.
## Decision produit
- Pas de remplacement complet de l'existant.
- Adoption incrementale:
1. garder MCP comme contrat commun,
2. aligner les handoffs et sessions sur les primitives de l'OpenAI Agents SDK,
3. reserver AutoGen/LangGraph a des lots compares et bornes,
4. conserver n8n / Wokwi / PlatformIO comme outillage complementaire et specialise.
docs/WEB_RESEARCH_DIGITAL_FACTORY_STACK_2026-03-22.md
+152
View File
@@ -0,0 +1,152 @@
# Web Research — Digital Factory Stack References
Date: 2026-03-22
Scope: lightweight reference set to position `Kill_LIFE` against reusable open-source or official stack patterns
## 1. Selected references
### Odoo PLM
Source:
- [Odoo PLM](https://www.odoo.com/app/plm)
Useful signal:
- strong `PLM` pattern around engineering change orders, document management, and versioning tied to manufacturing
Inference for `Kill_LIFE`:
- useful as a reference for the `PLM -> MES` handoff discipline
- not a direct reuse target for runtime orchestration
### ERPNext Manufacturing
Sources:
- [ERPNext Manufacturing](https://docs.frappe.io/erpnext/v12/user/manual/en/manufacturing)
- [ERPNext Bill of Materials](https://docs.frappe.io/erpnext/user/manual/en/bill-of-materials)
- [ERPNext Manufacturing Dashboard](https://docs.frappe.io/erpnext/v14/user/manual/en/manufacturing/manufacturing-dashboard)
Useful signal:
- concrete example of an integrated `ERP + MES + BOM + dashboard` loop
Inference for `Kill_LIFE`:
- relevant as a model for turning `Ops` priorities into executable work objects and dashboards
- useful conceptually for the `ERP / L'electronrare Ops` layer, not as a runtime replacement
### OpenBoxes
Sources:
- [OpenBoxes GitHub](https://github.com/openboxes/openboxes)
- [OpenBoxes website](https://openboxes.com/)
- [OpenBoxes features](https://openboxes.com/features/)
Useful signal:
- good open-source reference for `WMS` and supply-chain visibility
- emphasizes multi-location stock tracking, audit trails, and operational visibility
Inference for `Kill_LIFE`:
- useful for the `artifact / log / dataset / handoff` indexing mindset
- a conceptual reference for `WMS`, not a direct drop-in for `Kill_LIFE`
### Node-RED
Sources:
- [Node-RED Documentation](https://nodered.org/docs)
- [Node-RED Flow structure](https://nodered.org/docs/developing-flows/flow-structure)
- [Node-RED Documenting flows](https://nodered.org/docs/developing-flows/documenting-flows)
Useful signal:
- strong reference for low-friction operational flow design, flow documentation, and readable execution graphs
Inference for `Kill_LIFE`:
- useful for documenting and structuring operator flows and dispatch flows
- especially relevant for `MES` and `DCS` surface simplification
## 2. Reading for Kill_LIFE
Current best-fit reading:
- `PLM`: closer to `Odoo PLM` discipline than to ad hoc docs
- `ERP`: closer to an `ERPNext` governance mindset, but leaner and ops-first
- `WMS`: closer to `OpenBoxes` in the sense of auditable operational storage and retrieval
- `MES + DCS`: closer to `Node-RED` style flow discipline, but with shell/TUI, SSH mesh, and runtime checks instead of low-code nodes
## 3. Recommendation
Do not try to import a full external platform into `Kill_LIFE`.
Recommended path:
1. keep `Kill_LIFE` as the execution and continuity layer
2. formalize `ERP / L'electronrare Ops`
3. strengthen `WMS` indexing and retrieval
4. borrow documentation and flow-structure discipline from these references
## 4. Next useful research step
Potential next pass:
- compare `Odoo / ERPNext` change governance vs the current `Ops -> Kill_LIFE` lot model
- compare `OpenBoxes` audit trail patterns vs current `artifacts/` conventions
- compare `Node-RED` flow legibility patterns vs current cockpit TUI surface
## 5. Additional references for WMS and cockpit indexing
### MLflow Artifact Store
Source:
- https://mlflow.org/docs/latest/self-hosting/architecture/artifact-store/
Useful signal:
- clear separation between tracking metadata and artifact storage
- useful for thinking about `Kill_LIFE` as `registry contract + filesystem artifacts`
Inference for `Kill_LIFE`:
- keep metadata light and local
- avoid turning `artifacts/` into an unindexed dump
### Dagster Data Catalog / Software-defined assets
Sources:
- https://dagster.io/platform-overview/data-catalog
- https://dagster.io/blog/software-defined-assets
Useful signal:
- an asset catalog is most useful when ownership and dependency context stay close to the assets
Inference for `Kill_LIFE`:
- the WMS index should stay close to `specs/contracts/` and `artifacts/`
- explicit `owner_agent` and `consumer_layer` metadata is the right direction
### DVC Data Registry
Source:
- https://doc.dvc.org/use-cases/data-registry
Useful signal:
- strong reference for addressable and versioned data registry patterns
Inference for `Kill_LIFE`:
- especially relevant for dataset and fine-tune staging under the `WMS` layer
### Backstage Software Catalog
Sources:
- https://backstage.io/docs/features/software-catalog/
- https://backstage.io/docs/overview/what-is-backstage
Useful signal:
- strong model for a centralized catalog of ownership and metadata across software components
Inference for `Kill_LIFE`:
- relevant for the future cockpit layer index
- not as a platform to import, but as a pattern for `module -> owner -> metadata -> links`
### Rundeck Runbook Automation
Sources:
- https://docs.rundeck.com/docs/
- https://docs.rundeck.com/docs/about/introduction.html
Useful signal:
- good reference for runbook execution, operator workflows, and distributed automation across environments
Inference for `Kill_LIFE`:
- relevant for `MES + DCS` convergence and for exposing a more explicit runbook-oriented cockpit entrypoint
docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md
+102
View File
@@ -0,0 +1,102 @@
# Veille OSS — observabilité légère et incidents Mascarade (2026-03-21)
## Objectif
Identifier des briques open source ou officiellement documentées pour renforcer:
- le brief d'incident quotidien
- le registre d'incidents horodaté
- la synthèse hebdomadaire opératoire
- l'observabilité légère d'une pile locale/LLM
## Références retenues
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| Uptime Kuma | [Site officiel](https://uptimekuma.org/) et [wiki status page](https://github.com/louislam/uptime-kuma/wiki/Status-Page) | monitoring simple auto-hébergé, status pages, incidents légers, historique visuel | bon modèle pour garder une vue “status + incident + latest” lisible par opérateur sans stack lourde |
| Gatus | [Repo officiel](https://github.com/TwiN/gatus) | status page orientée développeur, alerting, incidents, configuration simple | pattern intéressant pour des checks déclaratifs Kill_LIFE/Mascarade et une sortie orientée endpoints/workflows |
| OpenObserve | [Site officiel](https://openobserve.ai/) et [repo officiel](https://github.com/openobserve/openobserve) | logs, metrics, traces, dashboards, alerts dans une seule brique open source | candidat naturel si la couche Mascarade/Ollama dépasse la TUI légère et demande une vraie observabilité centralisée |
| Grafana OnCall OSS | [Intro officielle](https://grafana.com/docs/oncall/latest/intro/) et [note de maintenance officielle](https://grafana.com/blog/grafana-oncall-maintenance-mode/) | workflow incident/on-call mature, mais maintenance mode documenté officiellement | utile comme référence UX/process, mais à éviter comme dépendance stratégique nouvelle vu son statut de maintenance |
| Netdata | [Open source](https://www.netdata.cloud/open-source/) et [alert notifications](https://learn.netdata.cloud/docs/alerts-%26-notifications/notifications/agent-dispatched-notifications/agent-notifications-reference) | observabilité temps réel légère, alertes par agent, faible coût d'entrée | bonne référence pour enrichir des snapshots temps réel et des alertes simples avant d'aller vers une pile plus lourde |
## Synthèse opérationnelle
- `Uptime Kuma` et `Gatus` sont les meilleures références pour un niveau “health + incident + statut opérateur” léger.
- `OpenObserve` est la meilleure piste si Kill_LIFE veut centraliser logs/metrics/traces autour de Mascarade, mesh et lanes opératoires.
- `Grafana OnCall OSS` reste utile comme benchmark de workflow incident, mais son statut de maintenance au 21 mars 2026 en fait une référence d'UX plus qu'une cible d'adoption.
- `Netdata` est la meilleure référence pour une observabilité locale très rapide à déployer si l'objectif est de compléter les scripts TUI par de l'alerte temps réel.
## Décision de lot
- Continuer en priorité avec la voie locale légère: `brief Markdown + registre d'incidents + TUI/logs`.
- Garder `OpenObserve` comme option de montée en puissance.
- Ne pas introduire de nouvelle dépendance incident lourde tant que la voie cockpit/TUI couvre correctement les besoins opératoires.
## Complément orienté incident knowledge / LLM observability
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| TheHive | [Introducing TheHive](https://blog.thehive-project.org/2016/11/07/introducing-thehive/) | workflow incident/alert/case collaboratif | bon benchmark pour faire évoluer le registre d'incidents horodaté vers une logique de cas et d'escalade |
| incident.io | [Understanding priority, urgency, and severity](https://docs.incident.io/articles/6990078692-understanding-priority%252C-urgency%252C-and-severity) | taxonomie claire entre sévérité, urgence et priorité | très utile pour garder un registre et une queue d'incidents sans ambiguïté de vocabulaire opératoire |
| Material for MkDocs | [Site officiel](https://squidfunk.github.io/mkdocs-material/) | publication Markdown rapide, searchable, maintenable | bon support si les briefs et synthèses doivent devenir un runbook vivant consultable hors repo brut |
| OpenTelemetry | [Docs officielles](https://opentelemetry.io/docs/) | standard neutre pour traces, métriques et logs | piste de normalisation si Kill_LIFE souhaite unifier plus tard la télémétrie agents/services/scripts |
| OpenTelemetry AI Agent Observability | [Blog officiel](https://opentelemetry.io/blog/2025/ai-agent-observability/) | instrumentation et corrélation spécifiques aux workflows d'agents IA | référence primaire utile si la couche Mascarade doit passer du simple brief/log à de vraies traces d'agents et spans métier |
| Grafana Loki | [Docs officielles](https://grafana.com/docs/loki/latest/) | agrégation de logs légère avec labels et requêtes | bonne référence si les logs cockpit/Mascarade deviennent trop volumineux pour la seule voie TUI |
| Langfuse | [Site officiel](https://langfuse.com/) | observabilité LLM, traces, evals, prompts, métriques | très pertinent pour comparer les runs des agents Mascarade et détecter les régressions de comportement |
Synthèse complémentaire:
- `incident.io` donne la meilleure base officielle pour distinguer `severity` et `priority`; c'est utile pour stabiliser la sémantique du registre et de la queue d'incidents.
- `TheHive` et `Material for MkDocs` sont surtout des références d'organisation et de publication du savoir opératoire.
- `OpenTelemetry` et sa note `AI Agent Observability` sont les meilleures pistes si la couche locale légère doit un jour devenir une vraie chaîne d'observabilité standardisée pour agents, services et scripts.
- `Langfuse` est la référence la plus directement exploitable pour une future observabilité spécifique aux agents et modèles Mascarade.
## Complément orienté watchboard / status page opérateur
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| OpenStatus | [Docs officielles](https://www.openstatus.dev/docs) | vues status/incidents très lisibles, timeline simple, endpoints publics orientés statut | bon benchmark pour faire évoluer `incident-watch` vers une vue publique ou semi-publique plus structurée |
| OneUptime | [Docs officielles](https://oneuptime.com/docs/introduction) | pile open source incidents + monitoring + status pages + on-call | référence intéressante si la couche cockpit devait un jour agréger dépendances, incidents et notifications dans une seule stack |
Synthèse watchboard:
- `OpenStatus` est une bonne référence de lisibilité pour les vues courtes `watch/status/latest`.
- `OneUptime` est plus large et plus lourd, mais reste un bon benchmark si Kill_LIFE veut unifier plus tard `monitoring + incidents + status pages`.
- Pour le lot courant, la bonne décision reste de conserver la voie légère locale `incident-watch` en TUI, sans introduire une nouvelle dépendance de prod.
## Complément orienté mémoire / reprise / confiance
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| LangChain Memory | [Concepts memory](https://docs.langchain.com/oss/python/concepts/memory) | distinction nette entre mémoire court terme de thread et mémoire long terme | confirme le découpage `ops = thread courant`, `kill_life = reprise durable / mémoire long terme` |
| LangGraph Memory | [Add memory](https://docs.langchain.com/oss/python/langgraph/add-memory) | `checkpointer`, persistance et reprise entre étapes / sous-graphes | renforce le choix d'un `resume_ref` stable et d'un artefact `latest` relu par plusieurs surfaces |
| AutoGen Memory | [Memory and RAG](https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/memory.html) | stores mémoire, query, update_context, stratégies de rappel | utile si `kill_life` doit évoluer d'une mémoire fichier vers un store plus riche inter-runs |
| OpenTelemetry AI Agent Observability | [Blog officiel](https://opentelemetry.io/blog/2025/ai-agent-observability/) | traces agents, corrélation tool calls / décisions / spans | valide le couple `trust_level + routing + artifacts` avant une instrumentation plus lourde |
Synthèse mémoire:
- garder une mémoire `latest` légère et lisible tant que le contrat produit continue d'évoluer.
- ne passer à un vrai store mémoire d'agent qu'après stabilisation de `resume_ref`, `trust_level`, `routing` et `memory_entry`.
## Complément orienté handoff léger / reprise opérateur
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| incident.io Scribe | [Documentation officielle](https://docs.incident.io/ai/scribe) | synthèse rapide pour quelqu'un qui rejoint ou reprend un incident sans relire toute la discussion | confirme l'intérêt d'un handoff court `latest + next steps + decisions` dans Kill_LIFE |
| incident.io On-call | [Getting started with On-call](https://docs.incident.io/on-call/getting-started) | explicite les `handover times` et la préparation de reprise côté astreinte | valide la présence d'une reprise courte et régulière dans les surfaces opérateur |
| PagerDuty My On-Call Shifts | [Documentation officielle](https://support.pagerduty.com/main/lang-ja/docs/my-on-call-shifts) | vue compacte `current + next` des responsabilités | bon benchmark pour les vues `watch + resume_ref + next_step` les plus courtes |
Synthèse handoff:
- garder une vue de reprise très courte, accessible sans navigation profonde, reste le meilleur pattern.
- la valeur n'est pas dans plus d'IA, mais dans une continuité visible: état courant, prochain pas, responsable, reprise.
## Complément orienté contrôle humain / exécution durable
| Projet | Source primaire | Ce qui est utile pour Kill_LIFE | Réutilisation concrète |
| --- | --- | --- | --- |
| LangGraph | [Overview officielle](https://docs.langchain.com/oss/python/langgraph/overview) | met en avant les agents stateful, le contrôle humain et la durabilité d'exécution | confirme qu'un contrat de reprise léger doit précéder toute orchestration plus profonde |
| AutoGen | [Memory and RAG](https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/memory.html) | montre comment la mémoire structure le rappel, le contexte et la reprise inter-runs | valide l'usage d'une mémoire `kill_life` commune avant d'ouvrir un store plus riche |
| OpenTelemetry | [AI Agent Observability](https://opentelemetry.io/blog/2025/ai-agent-observability/) | relie exécution d'agents, traces et supervision humaine | utile pour garder `trust_level + routing + artifacts` comme base d'explicabilité instrumentable plus tard |
Synthèse HITL/durable:
- la bonne séquence reste: `contrat produit stable -> mémoire de reprise lisible -> audit statique -> instrumentation plus lourde`.
- l'extension de surface seule n'apporte pas de fiabilité ; la valeur vient de la continuité et de la supervision humaine explicite.
- d'après la doc LangGraph sur le HITL et les interruptions, un bon système de reprise doit pouvoir `pause -> inspect -> approve/edit/reject -> resume`; c'est cohérent avec `resume_ref`, `trust_level` et un handoff court unique.
- la doc incident.io Scribe confirme qu'une synthèse et des moments clés servent surtout à permettre une reprise sans interrompre l'exécution en cours; c'est exactement le rôle du handoff produit minimal.
docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md
+215
View File
@@ -0,0 +1,215 @@
# Veille OSS (Open Source) — Refonte Kill_LIFE
Date: `2026-03-21`
Période de capture: `2026-03-20` → `2026-03-21` (révisions incrémentales recommandées toutes les 2 semaines)
Objectif: référencer les briques OSS utiles à la refonte IA-native, triées par surface et priorité.
Voir aussi: `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md` pour la vue dédiée KiCad/FreeCAD/OpenSCAD.
## Méthode d’évaluation
- Compatibilité protocol/cadence: capacité d’intégration dans `Kill_LIFE` (`agentic` / `MCP` / `host-first`) — 0 à 1.
- Qualité maintenable: qualité docs, activité récente, tests/CI — 0 à 1.
- Risque opérationnel: faible impact / pas de dépendances cachées / reversibilité — 1 = faible risque.
- Potentiel de plug-in immédiat dans le runtime — 0 à 1.
Score global = moyenne pondérée (0.30 + 0.30 + 0.20 + 0.20).
## Delta verification officielle 2026-03-21
Cette passe ajoute une verification a jour sur les sources officielles les plus structurantes pour `Kill_LIFE`.
| Source officielle | Date cle | Signal verifie | Decision Kill_LIFE |
| --- | --- | --- | --- |
| [MCP blog - November 2025 spec release](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/) | 2025-11-25 | MCP se confirme comme standard de fait; la release officielle ajoute une nouvelle version de la specification | **ADOPT NOW** pour les contrats et la couche discovery/outils |
| [MCP blog - next release update](https://blog.modelcontextprotocol.io/posts/2025-09-26-mcp-next-version-update/) | 2025-09-26 | la trajectoire 2025 mentionne explicitement structured tool outputs, OAuth-based authorization et elicitation | **ADOPT PARTIAL** pour la securite et la granularite des interactions; **DO NOT CLONE** tout le protocole de gouvernance |
| [VS Code Language Model Tool API](https://code.visualstudio.com/api/extension-guides/tools) | verifie 2026-03-21 | VS Code agent mode distingue `extension tools`, `built-in tools` et `MCP tools` | **ADOPT NOW** pour cadrer `studio/mesh/operator`: preferer MCP quand l'outil doit vivre hors VS Code, preferer tool natif quand l'integration editeur est essentielle |
| [VS Code Chat tutorial](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial) | publie recemment | les chat participants restent la voie officielle pour specialiser une extension autour d'un role clair | **ADOPT PARTIAL**: garder `@killstudio`, `@killmesh`, `@killops` tres specialises |
| [OpenAI Agents SDK - Agents](https://openai.github.io/openai-agents-python/agents/) | verifie 2026-03-21 | `tools`, `handoffs`, `mcp_servers`, `guardrails`, `output_type` sont des primitives stables | **ADOPT PARTIAL** comme vocabulaire et pattern de coordination |
| [OpenAI Agents SDK - Handoffs](https://openai.github.io/openai-agents-js/guides/handoffs/) | verifie 2026-03-21 | le handoff officiel renforce le pattern orchestrateur -> sous-agent specialise | **ADOPT PARTIAL** pour le format de relais court via `summary-short/v1` |
| [OpenAI Agents SDK - Tracing](https://openai.github.io/openai-agents-js/guides/tracing/) | verifie 2026-03-21 | tracing builtin pour runs, outils, handoffs, guardrails | **ADOPT PARTIAL** comme pattern d'observabilite, pas comme dependance centrale du cockpit |
| [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview) | verifie 2026-03-21 | durable execution, checkpoints, human-in-the-loop restent le coeur du positionnement | **DEFER**: overlay de workflows longs seulement apres stabilisation du control plane local |
Synthese de cette verification:
- `MCP` est confirme comme priorite d'integration numero 1.
- `VS Code` confirme une strategie hybride: tools natifs dans l'editeur quand necessaire, `MCP tools` pour les surfaces reutilisables.
- `OpenAI Agents SDK` est surtout une reference de patterns `handoffs/tools/tracing`, pas un coeur documentaire a adopter tel quel.
- `LangGraph` reste une option de niveau superieur pour l'orchestration longue, apres convergence des contrats et de la memoire cockpit.
## Tableaux candidats
### MCP et orchestration
| Projet | Score | Source | Usage visé |
| --- | --- | --- | --- |
| [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers) | 0.98 | GitHub | Référence des serveurs MCP maintenus, patterns de runtime, couverture de test |
| [Model Context Protocol Docs](https://modelcontextprotocol.io/docs/getting-started/intro) | 0.97 | Documentation officielle | Contrats, transport, sécurité, format JSON-RPC |
| [Model Context Protocol Registry](https://registry.modelcontextprotocol.io/) | 0.94 | Documentation officielle | Discovery et catalogues de serveurs externes |
| [openai-agents-python](https://openai.github.io/openai-agents-python/) | 0.84 | Documentation officielle | Sessions IA, runnables, gestion d’outils/handoff |
| [AutoGen](https://github.com/microsoft/autogen) | 0.82 | GitHub | Multi-agent patterns et délégation de tâches |
| [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) | 0.82 | Documentation officielle | Workflows longs + reprise d’état |
| [n8n](https://docs.n8n.io/) | 0.76 | Documentation officielle | Orchestration opérateur par flux no-code |
### CAD / KiCad / FreeCAD
| Projet | Score | Source | Usage visé |
| --- | --- | --- | --- |
| [lamaalrajih/kicad-mcp](https://github.com/lamaalrajih/kicad-mcp) | 0.89 | GitHub | Serveur MCP dédié KiCad, testable en prototype |
| [circuit-synth/kicad-sch-api](https://github.com/circuit-synth/kicad-sch-api) | 0.88 | GitHub | API HTTP ciblée sur schématique KiCad |
| [mixelpixx/KiCAD-MCP-Server](https://github.com/mixelpixx/KiCAD-MCP-Server) | 0.83 | GitHub | MCP complet KiCad (macOS/Linux/Windows), 52 outils annoncés |
| [Finerestaurant/kicad-mcp-python](https://github.com/Finerestaurant/kicad-mcp-python) | 0.81 | GitHub | Implémentation MCP via IPC officiel KiCad (stabilité potentielle) |
| [KiCad/KiCad](https://github.com/KiCad/KiCad) | 0.90 | GitHub officiel | Substrat upstream ECAD et base de fork YiACAD |
| [neka-nat/freecad-mcp](https://github.com/neka-nat/freecad-mcp) | 0.83 | GitHub | Serveur MCP FreeCAD expérimental |
| [jango-blockchained/mcp-freecad](https://github.com/jango-blockchained/mcp-freecad) | 0.78 | GitHub | Serveur MCP FreeCAD avec architecture plugin et exports |
| [ATOI-Ming/FreeCAD-MCP](https://github.com/ATOI-Ming/FreeCAD-MCP) | 0.80 | GitHub | PoC de pilotage FreeCAD via MCP |
| [contextform/freecad-mcp](https://github.com/contextform/freecad-mcp) | 0.81 | GitHub | MCP orienté CLAUDE + automation FreeCAD |
| [FreeCAD/FreeCAD](https://github.com/FreeCAD/FreeCAD) | 0.91 | GitHub officiel | Substrat upstream MCAD et base de fork YiACAD |
| [FreeCAD MCP (wujoseph)](https://wujoseph.com/work/freecad-mcp) | 0.70 | Personal portfolio | Projet annexe de preuve de concept IA-native |
| [FreeCAD Python API docs](https://wiki.freecadweb.org/FreeCAD_scripting_tutorial) | 0.77 | Documentation officielle | Scripts macro et automatisation locale |
| [KiCad documentation](https://docs.kicad.org/) | 0.72 | Documentation officielle | Référence stable des commandes et exports |
| [KiCad Automation Scripts](https://github.com/yaqwsx/KiKit) | 0.74 | GitHub | Génération automatique d’artefacts PCB |
| [easyw/kicadStepUpMod](https://github.com/easyw/kicadStepUpMod) | 0.88 | GitHub | Bridge ECAD/MCAD KiCad ↔ FreeCAD pour YiACAD |
| [CadQuery/cadquery](https://github.com/CadQuery/cadquery) | 0.84 | GitHub | Couche paramétrique Python complémentaire à FreeCAD/OpenSCAD |
| [KiCad GitHub Actions via Wokwi CI](https://docs.wokwi.com/wokwi-ci/github-actions) | 0.83 | Documentation officielle | Workflow de simulation/emulation embarquée |
### Veille de vérification rapide (mise à jour 2026-03-20)
- Les trois projets KiCad/FreeCAD MCP restent actifs mais hétérogènes côté maturité; priorité Kill_LIFE: **proto canari** puis **rétroaction lot**.
- Sources vérifiées récemment:
- [KiCad/KiCad](https://github.com/KiCad/KiCad) (upstream officiel)
- [FreeCAD/FreeCAD](https://github.com/FreeCAD/FreeCAD) (upstream officiel)
- [KiCad MCP by lamaalrajih](https://github.com/lamaalrajih/kicad-mcp) (GitHub)
- [FreeCAD MCP by ATOI-Ming](https://github.com/ATOI-Ming/FreeCAD-MCP) (GitHub)
- [FreeCAD MCP by neka-nat](https://github.com/neka-nat/freecad-mcp) (GitHub)
- [FreeCAD MCP (jango-blockchained)](https://github.com/jango-blockchained/mcp-freecad) (GitHub)
- [Projet FreeCAD MCP (wujoseph)](https://wujoseph.com/work/freecad-mcp) (cas pratique)
- [FreeCAD MCP (contextform)](https://github.com/contextform/freecad-mcp) (GitHub)
- [easyw/kicadStepUpMod](https://github.com/easyw/kicadStepUpMod) (bridge ECAD/MCAD)
- [CadQuery/cadquery](https://github.com/CadQuery/cadquery) (paramétrique Python)
### Firmware / validation continue
| Projet | Score | Source | Usage visé |
| --- | --- | --- | --- |
| [PlatformIO unit testing](https://docs.platformio.org/en/latest/advanced/unit-testing/index.html) | 0.80 | Documentation officielle | Validation robuste des lots firmware |
| [MCP runtime tooling](https://docs.platformio.org/en/latest/integration/github-actions.html) | 0.70 | Documentation officielle | CI GitHub standardisée |
| [Modeling + CAD automation scripts](https://wiki.freecadweb.org/Macro) | 0.69 | Documentation | Modèles de macro et scriptable |
### Répartition de charge / pilotage P2P (scripts op)
| Projet | Score | Source | Usage visé |
| --- | --- | --- | --- |
| [croniter](https://github.com/pallets-eco/croniter) | 0.72 | GitHub | Planification récurrente (TTL, audits, purges) côté TUI/shell |
| [apscheduler](https://github.com/agronholm/apscheduler) | 0.66 | GitHub | Scheduler applicatif léger pour health checks si pilotage Python futur |
| [Keepalived](https://www.keepalived.org/) | 0.70 | Documentation | Concepts de bascule/health checks de services dans architecture multi-hôtes |
| [HAProxy](https://www.haproxy.org/) | 0.78 | Documentation | Répartition de requêtes avec routage basé santé/charge |
| [supervisord](https://github.com/Supervisor/supervisor) | 0.66 | GitHub | Supervision processuelle et relance pour scripts de runbook |
### Agents et TUI opératoire (revue web complémentaire 2026-03-20)
| Projet | Score | Source | Usage visé |
| --- | --- | --- | --- |
| [LangGraph](https://github.com/langchain-ai/langgraph) | 0.84 | GitHub officiel | orchestration durable par lot, graphes d'etat et reprise |
| [AutoGen](https://github.com/microsoft/autogen) | 0.82 | GitHub officiel | sous-agents specialises et conversations outillees |
| [Textual](https://github.com/Textualize/textual) | 0.80 | GitHub officiel | TUI Python riche si le cockpit sort du shell pur |
| [prompt_toolkit](https://python-prompt-toolkit.readthedocs.io/) | 0.76 | Documentation officielle | prompts avances, completions, modes clavier |
| [Bubble Tea](https://github.com/charmbracelet/bubbletea) | 0.73 | GitHub officiel | reference d'ergonomie TUI evenementielle |
| [gum](https://github.com/charmbracelet/gum) | 0.78 | GitHub officiel | composants shell interactifs legers et reversibles |
### Chat multi-agents, presets et personas
| Projet | Source | Ce qui est utile pour Kill_LIFE | Reutilisation recommandee |
| --- | --- | --- | --- |
| [Open WebUI](https://docs.openwebui.com/features/) | [Repo officiel](https://github.com/open-webui/open-webui) | workspace multi-modeles, presets, personnages, projets et outils | inspirer les selecteurs d'agents `kxkm-*`, les panneaux de dispatch et les surfaces par usage |
| [LibreChat](https://www.librechat.ai/docs/configuration/librechat_yaml/object_structure/agents) | [Presets](https://www.librechat.ai/docs/user_guides/presets) | agents configurables, capacites explicites, presets partageables | garder des personas stables, appelables par nom dans le chat, avec capacites par lane |
| [LobeChat](https://github.com/lobehub/lobe-chat) | GitHub officiel | galerie d'agents, multi-providers, selection rapide de roles | reference pour un catalogue visuel de personas et un switch rapide entre lanes |
| [AnythingLLM](https://docs.anythingllm.com/) | [Repo officiel](https://github.com/Mintplex-Labs/anything-llm) | agent builder, skills, flows et logs | rattacher des competences/outils a des agents specialises, avec trace d'execution |
| [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) | [Repo officiel](https://github.com/langchain-ai/langgraph) | orchestration, memoire, supervision, human-in-the-loop | structurer `PM / Architect / SyncOps` comme graphe d'etat avec handoff et reprise |
Synthese operationnelle:
- `Open WebUI` et `LobeChat` sont les meilleurs points d'appui pour les surfaces `presets/personas`.
- `LibreChat` et `AnythingLLM` sont les plus proches d'une logique `agent builder + skills + capacites`.
- `LangGraph` reste la meilleure reference pour industrialiser l'orchestration des agents dedies par specification et module.
### Benchmark 2026 — patterns retenus pour `summary-short` et la gateway santé `runtime/MCP/IA` (mise à jour 2026-03-21)
Cette note reste la note benchmark transverse de référence. Les autres docs doivent la citer, pas recopier ces décisions.
| Pattern / source primaire | Signal utile | Adoption concrète |
| --- | --- | --- |
| [Model Context Protocol Docs](https://modelcontextprotocol.io/docs/getting-started/intro) + [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers) | contrat unique pour discovery, outils, transport et sécurité MCP | **ADOPT NOW** pour la gateway de santé: une seule surface normalise `runtime`, `mcp`, `tools`, `degraded_reason`; pas de checks disparates par extension |
| [MCP Registry](https://registry.modelcontextprotocol.io/) | catalogue vivant pour discovery et comparaison de serveurs | **BENCHMARK ONLY**: utile pour comparer et qualifier, mais pas dépendance runtime à court terme |
| [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/) | patterns `sessions`, `handoffs`, `tools`, `tracing` | **ADOPT PARTIAL** pour le vocabulaire de relais et le format de handoff; **DO NOT ADOPT** comme coeur documentaire ou runtime structurant |
| [OpenHands](https://github.com/OpenHands/OpenHands) | séparation claire `SDK / CLI / GUI / Cloud / Enterprise` | **ADOPT NOW** comme pattern d'architecture: `studio` produit les artefacts, `mesh` porte la gateway runtime, `operator` exécute et supervise; **DO NOT CLONE** le produit |
| [Roo Code](https://github.com/RooCodeInc/Roo-Code) + [VS Code AI extensibility](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial) | rôles visibles dans l'éditeur, modes spécialisés, usage outillé/MCP | **ADOPT PARTIAL**: garder des lanes explicites et bornées; **DO NOT ADOPT** une "team" autonome large ou une prolifération de modes |
| [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview) | durable execution, checkpoints, human-in-the-loop | **DEFER**: overlay possible pour les workflows longs seulement après stabilisation de `summary-short` et de la gateway de santé |
Décisions d'adoption 2026-03-21:
1. `summary-short` est **adopté** comme artefact canonique de relais court, d'abord dans `kill-life-studio`.
2. Format cible `summary-short`: `goal / state / blockers / next / owner / evidence` en sortie courte et déterministe.
3. `summary-short` n'est **pas** un transcript, ni une mémoire libre de type agent framework; c'est un contrat de handoff compact.
4. La gateway santé `runtime/MCP/IA` est **adoptée** comme source unique d'état technique pour `mesh` et `operator`.
5. La gateway doit exposer au minimum: `runtime_ok`, `mcp_ok`, `llm_ok`, `tools_count`, `degraded_reason`, `last_check`.
6. `kill-life-studio` consomme cette santé en lecture seule; il ne devient pas cockpit runtime.
7. `kill-life-mesh` porte la normalisation et l'agrégation de santé; `kill-life-operator` consomme cette sortie pour les checks et runbooks.
8. `Roo Code`, `OpenHands`, `OpenAI Agents SDK` et `LangGraph` restent des références de pattern; aucune de ces briques n'est adoptée telle quelle comme dépendance centrale court terme.
Conséquence produit immédiate:
- `Studio` produit les `summary-short` et autres artefacts de cadrage.
- `Mesh` expose une gateway de santé unique `runtime/MCP/IA` et relaie des états courts.
- `Operator` s'appuie sur cette gateway pour l'action opératoire, pas sur des probes parallèles.
### Références officielles 2026 vérifiées
- [VS Code AI extensibility](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial)
- [Model Context Protocol intro](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Model Context Protocol registry](https://registry.modelcontextprotocol.io/)
- [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/)
- [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview)
## Recommandation de déploiement Kill_LIFE
### Niveau 1 — Immédiat (safe, faible risque)
1. Consolider le noyau MCP à partir de la spec officielle (`modelcontextprotocol/servers`, docs MCP).
2. Finaliser les guards et gates autour d’`openai-agents-python` en mode piloté (`ai:plan`, `ai:tasks`, `ai:qa`).
3. Standardiser la matrice de contrôle Wokwi + PlatformIO pour les lots `firmware`.
### Niveau 2 — Court terme (expérimental contrôlé)
1. Intégrer `lamaalrajih/kicad-mcp` ou alternative équivalente en lane canari IA-native.
2. Tester `circuit-synth/kicad-sch-api` pour validation de schéma et linting ciblé.
3. Evaluer une des implémentations FreeCAD MCP (`neka-nat/freecad-mcp` ou `ATOI-Ming/FreeCAD-MCP`) en mode non bloquant.
4. Poser YiACAD sur le triptyque `KiCad/KiCad` + `FreeCAD/FreeCAD` + `easyw/kicadStepUpMod`.
### Niveau 3 — Moyen terme (pilotage orchestration)
1. Orchestration longue durée des lots avec LangGraph ou AutoGen.
2. Lier une surface n8n à des jobs d’opérateur pour la routine quotidienne.
3. Déployer un tableau de bord d’acceptation par surface (MCP/CAD/Firmware/logs).
### Synthèse ciblée 2026-03-20
- Court terme: rester sur `bash-cli-tui` + shell TUI pour `Kill_LIFE`, avec `gum` comme couche interactive facultative.
- Moyen terme: garder `Textual` et `prompt_toolkit` comme options de montée en gamme si le cockpit devient trop complexe pour Bash.
- Agentique: traiter `LangGraph` et `AutoGen` comme overlays contrôlés, pas comme source de vérité documentaire ou planificatrice.
## Cartographie d’alignement Kill_LIFE
| Surface | Projection d’intégration | Garde-fou |
| --- | --- | --- |
| `specs` + docs | A2A / IA planificateur documentaire (`ai:spec`, `ai:plan`, `ai:tasks`) | `python3 tools/validate_specs.py --strict --require-mirror-sync` |
| MCP / outils runtime | Lancement canari + observabilité (`tools/mcp_runtime_status.py`, `mesh`) | `run_and_log`, mode `degraded` explicitement géré |
| CAD / forks IA-native | Lane isolée `kill-life-ai-native` et preuves par lot | Aucun merge direct; `write_set` explicite |
| logs / conformité | Refonte TUI + purge contrôlée | `bash tools/cockpit/log_ops.sh` avec rétention et proof |
## Décision d’intégration (mise à jour 2026-03-20)
- Les intégrations actives restent en mode assisté (`ai:spec`, `ai:plan`, `ai:tasks`) sauf lot explicitement en pilotage.
- Chaque nouvelle expérimentation doit créer un lot dans `specs/04_tasks.md` avec preuves de log et rollback.
- Toute proposition de branche/merge doit passer par les contrats `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md` + handoff.
- Le substrat recommandé pour YiACAD est désormais: upstreams officiels (`KiCad/KiCad`, `FreeCAD/FreeCAD`), bridge ECAD/MCAD (`easyw/kicadStepUpMod`) et adaptateurs MCP en lane canari.
docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-22.md
+36
View File
@@ -0,0 +1,36 @@
# Web research open source / MCP / AI 2026-03-22
## Delta verification officielle 2026-03-22
| Source officielle | Signal verifie | Decision Kill_LIFE |
| --- | --- | --- |
| [Model Context Protocol intro](https://modelcontextprotocol.io/docs/getting-started/intro) + [MCP registry](https://registry.modelcontextprotocol.io/) | MCP remains the preferred standard boundary for tool discovery and external tool contracts. | Keep MCP as the preferred boundary for parts search, CI triggers, artifact fetch and ops summary; do not force MCP inside Git/Yjs persistence. |
| [OpenAI tools guide](https://developers.openai.com/api/docs/guides/tools) | The current OpenAI platform groups tools, MCP/connectors, WebSocket mode, background mode and agent-oriented surfaces under one tools-first model. | If web AI assist opens, keep it tools-first and read-only at first. Use it above Git/Yjs/workers, not instead of them. |
| [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/) | Official patterns center on tools, handoffs, tracing and sessions. | Keep Agents SDK as a reference for handoffs/tracing patterns only; not as the project source of truth. |
| [LangGraph overview](https://docs.langchain.com/oss/python/langgraph/overview) | LangGraph remains focused on durable execution, human-in-the-loop and long-running stateful agents. | Defer LangGraph until contracts, Git read model, artifacts and realtime are stable. |
| [VS Code Language Model Tool API](https://code.visualstudio.com/api/extension-guides/tools) + [Chat tutorial](https://code.visualstudio.com/api/extension-guides/ai/chat-tutorial) | VS Code positions built-in tools, extension tools and MCP tools as first-class building blocks. | Keep extension lanes light and cross-environment tool contracts on MCP/service boundaries. |
| [Excalidraw](https://github.com/excalidraw/excalidraw) | React embedding and JSON scene storage remain practical for Git-tracked architecture diagrams. | Keep `.excalidraw` JSON in Git. Bind collaboration through Yjs, but keep explicit snapshot/save semantics. |
| [Yjs docs](https://docs.yjs.dev/) | Yjs remains a strong CRDT choice for collaborative state and presence. | Use Yjs for room state and presence only. Git remains the product source of truth. |
| [KiCanvas embedding](https://kicanvas.org/embedding/) | The official docs still recommend vendoring the bundled `kicanvas.js` during alpha. | Keep `web/public/vendor/kicanvas.js` vendored and avoid runtime CDN coupling. |
| [KiBot](https://github.com/INTI-CMNB/KiBot) | KiBot remains the practical automation layer for reproducible outputs around KiCad. | Keep worker support for real KiBot binaries and a repo-level config path. |
| [KiAuto](https://github.com/INTI-CMNB/KiAuto) | KiAuto still fills the gap for ERC/DRC automation and GUI-driven KiCad flows. | Keep KiAuto as an explicit optional worker dependency, not an implicit runtime assumption. |
| [BullMQ docs](https://docs.bullmq.io/) | BullMQ remains a pragmatic Redis-backed queue for JS workers. | Keep BullMQ as the first queue contract for `web/`; do not introduce Kafka before real throughput pressure exists. |
## Package surface verified locally on 2026-03-22
- `@excalidraw/excalidraw`: `0.18.0`
- `next`: `16.2.1`
- `react`: `19.2.4`
- `graphql-yoga`: `5.18.1`
- `yjs`: `13.6.30`
- `y-websocket`: `3.0.0`
- `bullmq`: `5.71.0`
## Similar / usable OSS stack already aligned with the product
- `Excalidraw` for diagram editing
- `KiCanvas` for embedded board/schematic viewing
- `Yjs` for collaborative room state
- `BullMQ + Redis` for worker dispatch
- `KiBot` and `KiAuto` for EDA CI
- `KiCad` and `FreeCAD` remain the core native CAD engines behind YiACAD
docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md
+117
View File
@@ -0,0 +1,117 @@
# YiACAD UI/UX Audit Apple-native - 2026-03-20
## Portée
Audit de la refonte UI/UX pour `YiACAD`, base `KiCad + FreeCAD` pilotée par la lane IA-native de `Kill_LIFE`, aligné sur les recommandations Apple officielles disponibles au `2026-03-20`.
## Résumé exécutif
YiACAD possède déjà trois atouts structurels forts:
- une base outillée et traçable;
- des surfaces CAD déjà installées dans les répertoires utilisateur;
- une culture de preuve par artefacts, lots et runbooks.
Le point faible principal n’est pas l’absence de fonctions, mais leur fragmentation. Aujourd’hui, l’opérateur passe entre cockpit, plugin KiCad, workbench FreeCAD, artefacts markdown et scripts shell. La refonte UI/UX doit donc unifier l’expérience autour d’un shell cohérent, lisible, hiérarchisé, avec des actions IA visibles mais discrètes.
## Points forts
- Gouvernance déjà spec-first avec plans, TODOs, artefacts et runbooks.
- Surfaces natives déjà présentes dans les répertoires utilisateur KiCad et FreeCAD.
- Utilitaires IA concrets déjà posés pour `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync` et `Status`.
- Pipeline de logs et d’artefacts déjà compatible avec une expérience “inspectable”.
- Découpage agentique permettant d’isoler clairement `PM`, `Architect`, `SyncOps` et désormais `DesignOps-UI`.
## Points faibles
- Absence d’architecture d’information commune entre KiCad, FreeCAD et le cockpit.
- Boutons présents, mais hiérarchie d’action encore insuffisante: pas de `command palette`, pas de regroupement par tâche, peu d’états visuels.
- Trop de surfaces textuelles secondaires pour accéder à l’essentiel: l’utilisateur doit déjà savoir quoi lancer.
- Le shell IA est encore largement Python/plugin-level, pas encore compilé et natif au cœur des forks.
- Peu de conventions visuelles partagées entre `status`, `review`, `sync`, `artifacts`.
## Opportunités majeures
- Unifier l’architecture en `sidebar -> canvas -> inspector`.
- Introduire une `command palette` commune pour les actions transverses.
- Transformer l’IA en couche d’assistance contextuelle, jamais en panneau bavard permanent.
- Faire du `review center` la destination unique pour `ERC`, `DRC`, `BOM`, `sync`, warnings, suggestions et preuves.
- Aligner les surfaces sur les patterns Apple/macOS: toolbars sobres, sidebars claires, search field centrale, inspecteurs contextuels, SF Symbols cohérents, génération IA explicitement balisée.
## Recommandations Apple 2026 retenues
### Structure
- Utiliser une navigation stable et visible.
- Réduire la concurrence visuelle dans la toolbar.
- Préférer les inspecteurs contextuels plutôt que des modales répétées.
- Donner à la recherche et aux commandes une place de premier rang.
### IA
- Signaler explicitement quand une sortie est générée ou suggérée par IA.
- Garder l’utilisateur en contrôle de l’action finale.
- Présenter le résultat avec source, contexte, confiance et possibilité d’annulation.
- Utiliser l’IA pour accélérer la tâche, pas pour masquer l’état du système.
## Architecture cible
```mermaid
flowchart LR
Sidebar["Sidebar<br/>Projet / Review / Sync / Artifacts"] --> Canvas["Canvas principal<br/>EDA / MCAD / Preview / Diff"]
Canvas --> Inspector["Inspector contextuel<br/>Props / warnings / AI suggestions / provenance"]
Toolbar["Toolbar sémantique<br/>Search / Command / Review / Sync"] --> Canvas
Palette["Command palette<br/>review.erc_drc / review.bom / sync.ecad_mcad / ai.explain"] --> Canvas
AI["AI assistance lane<br/>suggest / summarize / trace"] --> Inspector
Logs["Artifacts + logs"] --> Inspector
```
## Carte des écarts
| Surface | État actuel | Écart | Cible |
| --- | --- | --- | --- |
| KiCad plugin | boutons fonctionnels, surface modale | trop plate, peu hiérarchisée | palette + review center + inspector |
| FreeCAD workbench | commandes disponibles | peu de narration d’état et peu de convergence visuelle | dock d’assistance + sync panel |
| Cockpit | puissant mais orienté lot | peu tourné usage design quotidien | TUI dédiée UI/UX + résumés ciblés |
| Documentation | riche | dispersée | un corpus UI/UX relié depuis le README et le manifeste |
| Forks natifs | hooks directs présents | pas encore intégrés aux surfaces compilées | shell natif YiACAD |
## Intégration IA recommandée
| Cas d’usage | Entrée | Sortie | Garde-fou |
| --- | --- | --- | --- |
| `ERC/DRC Assist` | board + schematic + violations | regroupement des priorités, suggestions de correction | ne jamais auto-appliquer |
| `BOM Review` | BOM exportée | manquants, duplications, champs vides | lister les preuves et les lignes concernées |
| `ECAD/MCAD Sync` | STEP KiCad + STEP FreeCAD | delta, état d’alignement, lot de preuves | conserver les deux exports bruts |
| `AI Explain` | warning sélectionné | explication + contexte + doc liée | source et confiance visibles |
| `Review Digest` | artefacts d’un lot | résumé opérateur | lien vers artefacts originaux |
## Phasage recommandé
### P0
- stabiliser la taxonomie visuelle des actions;
- publier le shell documentaire et la TUI UI/UX;
- préparer l’intégration native des hooks dans les forks.
### P1
- introduire la `command palette` unifiée;
- créer le `review center`;
- ajouter les inspecteurs contextuels KiCad/FreeCAD.
### P2
- remonter ces patterns dans le code natif compilé des forks;
- ouvrir la voie à `App Intents`, `Spotlight actions` et modèles on-device lorsque la pile le permet;
- mesurer adoption, latence et taux d’usage.
## Risques
- surcouche “Apple-like” superficielle sans gain métier;
- duplication entre plugin Python temporaire et shell natif futur;
- confusion si les états IA ne sont pas parfaitement explicités.
## Décision de passe
La bonne trajectoire n’est pas de “repeindre” les boutons. Il faut construire un shell opératoire unique, centré sur les workflows `review`, `sync`, `inspect`, `artifacts`, avec une IA contextuelle, traçable et toujours réversible.
docs/YIACAD_APPLE_UI_UX_FEATURE_MAP_2026-03-20.md
+77
View File
@@ -0,0 +1,77 @@
# YiACAD Apple-native UI/UX Feature Map - 2026-03-20
## Carte fonctionnelle
```mermaid
flowchart TD
YIACAD[YiACAD Apple-native shell]
YIACAD --> NAV[Navigation Sidebar]
YIACAD --> TOOLBAR[Semantic Toolbar]
YIACAD --> PALETTE[Command Palette]
YIACAD --> CANVAS[ECAD / MCAD Canvas]
YIACAD --> INSPECTOR[Context Inspector]
YIACAD --> REVIEW[Review Center]
YIACAD --> ARTIFACTS[Artifacts & Logs]
YIACAD --> AI[AI Assist Layer]
NAV --> PROJECT[Project Overview]
NAV --> BOM[BOM Review]
NAV --> ERCDRC[ERC / DRC Review]
NAV --> SYNC[ECAD / MCAD Sync]
NAV --> HISTORY[Lots / History]
TOOLBAR --> SEARCH[Search / Filter]
TOOLBAR --> STATUS[Status]
TOOLBAR --> ACTIONS[Primary actions]
PALETTE --> CMD_REVIEW[review.erc_drc]
PALETTE --> CMD_BOM[review.bom]
PALETTE --> CMD_SYNC[sync.ecad_mcad]
PALETTE --> CMD_EXPLAIN[ai.explain]
PALETTE --> CMD_ARTIFACTS[open.artifacts]
REVIEW --> WARNINGS[Warnings grouped by severity]
REVIEW --> DIGEST[AI digest]
REVIEW --> SOURCES[Evidence links]
REVIEW --> RESULT_CARD[Normalized result card]
AI --> SUGGEST[Suggested fixes]
AI --> SUMMARIZE[Summaries]
AI --> TRACE[Traceability / provenance]
ARTIFACTS --> LOGS[Logs]
ARTIFACTS --> REPORTS[Markdown reports]
ARTIFACTS --> EXPORTS[STEP / BOM / ERC / DRC]
RESULT_CARD --> SEVERITY[Severity]
RESULT_CARD --> NEXT[Next steps]
RESULT_CARD --> CONTRACT[done | degraded | blocked]
```
## Surfaces
| Surface | Rôle | État |
| --- | --- | --- |
| Navigation Sidebar | point d’entrée orienté tâches | à intégrer dans les forks natifs |
| Semantic Toolbar | recherche, statut, action principale | à intégrer dans les forks natifs |
| Command Palette | actions transverses unifiées | première palette légère livrée dans les surfaces YiACAD natives; intégration shell profonde ouverte |
| Review Center | centraliser `ERC`, `DRC`, `BOM`, `sync` | regroupement léger livré dans les surfaces YiACAD; consolidation multi-surface ouverte |
| Context Inspector | détail, explication IA, provenance | partiellement disponible: dock persistant FreeCAD + sortie inspecteur KiCad |
| Artifacts Browser | accès direct aux preuves et exports | partiellement disponible |
| UI/UX TUI | pilotage audit, synthèse, purge logs | disponible via script dédié |
| Output Contract | carte de résultat normalisée pour `status`, `severity`, `artifacts`, `next_steps` | publié dans `docs/YIACAD_UIUX_OUTPUT_CONTRACT_2026-03-20.md` + `specs/contracts/yiacad_uiux_output.schema.json` |
## Canon des lots
- `T-UX-003`: montée native progressive vers les points d’insertion shell/workbench documentés.
- `T-UX-004`: contrat `command palette + inspector persistant` d’abord dans les surfaces déjà contrôlées par YiACAD.
- `UI/UX TUI`: support ops livré, hors numérotation canonique `T-UX-003`.
## Delta 2026-03-20 22:49 - output contract
- `T-UX-004B` publie le contrat de sortie UX commun pour les actions YiACAD.
- Le contrat normalise `status`, `severity`, `summary`, `details`, `artifacts`, `next_steps`, `surface`, `context_ref` et `execution_mode`.
- Les preuves canoniques deviennent:
- `docs/YIACAD_UIUX_OUTPUT_CONTRACT_2026-03-20.md`
- `specs/contracts/yiacad_uiux_output.schema.json`
- `specs/contracts/examples/yiacad_uiux_output.example.json`
docs/YIACAD_APPLE_UI_UX_OSS_RESEARCH_2026-03-20.md
+53
View File
@@ -0,0 +1,53 @@
# YiACAD UI/UX Apple-native - Web Research OSS - 2026-03-20
## Sources Apple officielles
| Source | Apport pour YiACAD |
| --- | --- |
| [Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) | ancrage global des patterns de navigation, toolbars, search fields et inspectors |
| [Human Interface Guidelines for Generative AI](https://developer.apple.com/design/human-interface-guidelines/generative-ai) | cadrage des affordances IA: contrôle utilisateur, transparence, provenance |
| [Design - What's new](https://developer.apple.com/design/whats-new/) | confirme les surfaces Apple actuelles à privilégier pour une refonte alignée |
| [App Intents](https://developer.apple.com/documentation/AppIntents) | ouvre la piste des commandes système, Spotlight et automatisations natives |
| [Foundation Models framework](https://developer.apple.com/apple-intelligence/whats-new/) | trajectoire future pour assistance locale et on-device si la stack cible évolue |
| [Liquid Glass technology overview](https://developer.apple.com/documentation/technologyoverviews/liquid-glass) | utile comme direction visuelle prudente: profondeur, hiérarchie, matière, sans bruit |
## Synthèse Apple retenue
- placer navigation, recherche et actions essentielles au premier niveau;
- limiter le nombre d’actions visibles dans la toolbar;
- faire des inspecteurs contextuels la destination des détails;
- exposer l’IA comme suggestion ou accélération, jamais comme autorité opaque;
- conserver une forte lisibilité des états et de la provenance.
## OSS / briques exploitables
| Projet | Usage potentiel |
| --- | --- |
| [KiCad](https://github.com/KiCad/kicad-source-mirror) | base ECAD native à faire évoluer côté menus, toolbar et panneaux |
| [FreeCAD](https://github.com/FreeCAD/FreeCAD) | base MCAD/workbench à aligner avec le shell YiACAD |
| [KiCad StepUp](https://github.com/easyw/kicadStepUpMod) | référence concrète de pont ECAD/MCAD entre KiCad et FreeCAD |
| [CadQuery](https://github.com/CadQuery/cadquery) | moteur paramétrique utile pour génération/sync guidée |
| [CQ-editor](https://github.com/CadQuery/CQ-editor) | exemple de shell de modélisation avec panneau et commandes dédiées |
| [kicad-mcp](https://github.com/lamaalrajih/kicad-mcp) | interface MCP exploitable pour assistance KiCad plus fine |
## Décisions intégrées
- conserver KiCad et FreeCAD comme socles, pas comme cibles à masquer;
- prendre `KiCad StepUp` comme référence fonctionnelle pour le volet sync ECAD/MCAD;
- utiliser `CadQuery` comme brique optionnelle d’automatisation future, pas comme shell principal;
- faire converger les surfaces autour d’un shell YiACAD commun avant toute montée en sophistication visuelle.
## Delta 2026-03-20 18:12 - Références officielles shell natif
- [KiCad PCB Python Bindings - Action Plugin support](https://dev-docs.kicad.org/en/apis-and-binding/pcbnew/index.html)
- confirme que les plugins/actions KiCad peuvent apparaître dans le menu des plugins externes et, si le plugin suit les conventions attendues, exposer un bouton de toolbar.
- implication YiACAD: un regroupement shell `YiACAD Review` dans les toolbars reste cohérent avec le modèle upstream.
- [KiCad IPC API - For add-on developers](https://dev-docs.kicad.org/en/apis-and-binding/ipc-api/for-addon-developers/index.html)
- confirme que les actions d’add-on peuvent aussi s’enregistrer sur la toolbar du PCB editor.
- implication YiACAD: le lot shell actuel reste compatible avec une trajectoire future vers des add-ons/IPC plus propres.
- [FreeCAD DockWindowManager class reference](https://freecad.github.io/SourceDoc/d9/d72/classGui_1_1DockWindowManager.html)
- documente l’enregistrement de docks nommés et le fait que les workbenches doivent préparer leurs dock windows.
- implication YiACAD: le `YiACAD Inspector` doit rester un dock explicitement nommé et persistant.
- [FreeCAD Developers Handbook - Dock Windows](https://freecad.github.io/DevelopersHandbook/designguide/elements.html)
- confirme que les docks sont la destination naturelle des panneaux orientés tâche et que les widgets de toolbar plus atypiques demandent davantage de discipline UX.
- implication YiACAD: l’inspector/review center doit rester côté dock; la toolbar doit surtout jouer le rôle d’entrée rapide.
docs/YIACAD_AUTONOMOUS_LOT_CHAIN_2026-03-21.md
+51
View File
@@ -0,0 +1,51 @@
# YiACAD autonomous lot chain - 2026-03-21
## Scope
- Consolidate `T-ARCH-101C` after the backend service-first cutover.
- Consolidate `T-OPS-119` after the operator index rationalization.
- Prepare the next minimal autonomous lot without disturbing concurrent work.
## Lots completed in this pass
- `T-ARCH-101C` extended to compiled KiCad surfaces.
- `T-OPS-119` consolidated around the stable operator index.
## Agents and ownership
- `Arendt`: compiled KiCad surfaces and service-first migration.
- `Rawls`: operator index, TUI routing, operator documentation.
- `Ampere`: analysis of remaining deep CAD call sites not yet on backend client.
- `Archimedes`: analysis of remaining operator alias, log hygiene and TUI rationalization work.
## Delivered paths
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad/yiacad_backend_service.py`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad/yiacad_backend_client.py`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/yiacad_backend_service_tui.sh`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/yiacad_operator_index.sh`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/YIACAD_BACKEND_SERVICE_2026-03-21.md`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/YIACAD_OPERATOR_INDEX_2026-03-21.md`
## Remaining risks
- No execution validation has been run in opened KiCad or FreeCAD.
- Some deep compiled call sites may still bypass `yiacad_backend_client.py`.
- Compatibility aliases intentionally keep historical operator routes alive.
- `yiacad-fusion` remains blocked outside this repository on the host KiCad entrypoint in `mascarade-main`.
## Next decision rule
- If deep compiled call sites remain, prioritize the smallest lot that migrates them to `service-first`.
- Otherwise, prioritize the smallest lot that removes operator duplication while preserving non-interactive compatibility.
- Keep append-only or new-file writes when possible because the codebase is shared.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
## 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.
## 2026-03-21 - Operator cleanup
- Duplicate `review-context` alias removed from `tools/cockpit/yiacad_operator_index.sh`.
- Public docs now point to the operator index as the recommended entry.
- Logs and proofs now have dedicated canonical surfaces.
docs/YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md
+94
View File
@@ -0,0 +1,94 @@
# YiACAD backend architecture (2026-03-20)
## Intent
Stabiliser la couche locale YiACAD entre les shells natifs KiCad/FreeCAD, les TUI et les utilitaires CAD. Le but n'est plus seulement d'executer des commandes, mais de fournir un contexte projet commun, des artefacts structurés et un contrat de sortie uniforme.
## Etat courant
- les shells natifs appellent `tools/cad/yiacad_native_ops.py`
- `yiacad_native_ops.py` reste le runner concret des actions `status`, `ERC/DRC`, `BOM review`, `ECAD/MCAD sync`
- le nouveau module `tools/cad/yiacad_backend.py` pose la couche backend locale commune:
- `context broker`
- `surface inference`
- `context_ref`
- `uiux_output.json`
- `context.json`
## Architecture cible locale
```mermaid
flowchart LR
UI["KiCad / FreeCAD / TUI"] --> Broker["yiacad_backend.py"]
Broker --> Context["context broker"]
Broker --> Contract["uiux output contract"]
Broker --> NativeOps["yiacad_native_ops.py"]
NativeOps --> Reports["reports / exports / logs"]
Context --> Reports
Contract --> Reports
Reports --> Review["review center / inspector / artifacts"]
```
## Ce que T-ARCH-101 livre maintenant
- un backend local partage dans `tools/cad/yiacad_backend.py`
- une facade backend locale adressable dans `tools/cad/yiacad_backend_service.py`
- une resolution de contexte unifiee pour:
- `source_path`
- `board`
- `schematic`
- `freecad_document`
- `context_ref`
- un artefact `context.json` par run YiACAD
- un artefact `uiux_output.json` par run YiACAD
- un mode `--json-output` dans `tools/cad/yiacad_native_ops.py` pour exposer directement le contrat structure
## Ce qui reste a faire
### T-ARCH-101B
- sortir d'un simple appel de script local vers une couche backend plus robuste
- permettre aux shells natifs d'appeler une API locale stable plutot qu'une CLI seule
### T-ARCH-101C
- brancher `review center`, `palette` et `inspector` sur `uiux_output.json`
- rendre le `context broker` reusable entre KiCad, FreeCAD et TUI sans duplication
## Contrats relies
- sortie UX:
- `specs/contracts/yiacad_uiux_output.schema.json`
- `specs/contracts/examples/yiacad_uiux_output.example.json`
- contexte backend:
- `specs/contracts/yiacad_context_broker.schema.json`
- `specs/contracts/examples/yiacad_context_broker.example.json`
## Lecture courte
1. `yiacad_native_ops.py` reste le moteur concret.
2. `yiacad_backend.py` devient la couche commune de contexte et de contrat.
3. le prochain saut consiste a remplacer la simple invocation locale par un backend YiACAD plus stable et plus adressable.
## Delta 2026-03-21 - backend facade addressable
- `T-ARCH-101` est considere comme ferme: backend local, `context broker`, sorties normalisees et facade adressable sont maintenant publies.
- `tools/cad/yiacad_backend_service.py` fournit un point d’entree local stable pour:
- `status`
- `invoke status`
- `invoke kicad-erc-drc`
- `invoke bom-review`
- `invoke ecad-mcad-sync`
- `T-ARCH-101C` est maintenant execute sur les surfaces actives: la facade locale est prouvee operatoirement et promue jusque dans la TUI UI/UX.
## Delta 2026-03-21 - shell helpers rerouted
- les helpers shell Python KiCad et FreeCAD privilegient maintenant `tools/cad/yiacad_backend_service.py` comme transport local:
- `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin/_native_common.py`
- `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- `tools/cockpit/yiacad_uiux_tui.sh --action status` consomme maintenant le meme client `service-first`.
- le fallback direct vers `tools/cad/yiacad_native_ops.py` reste present si la facade locale est absente.
- la suite se deplace maintenant vers:
- `T-UX-004` pour la palette et l'inspector persistants,
- `T-UX-003` pour les points d'insertion natifs plus profonds,
- `T-RE-209` pour le lot operateur YiACAD complet.
docs/YIACAD_BACKEND_OPERATOR_PROOF_2026-03-21.md
+60
View File
@@ -0,0 +1,60 @@
# YiACAD Backend Operator Proof - 2026-03-21
## Objectif
Publier une preuve opérateur canonique qui valide, sans ouvrir les GUI complètes, la chaîne:
- helper shell KiCad
- helper workbench FreeCAD
- façade locale `tools/cad/yiacad_backend_service.py`
- contrat `uiux_output`
## Entrée canonique
- commande: `bash tools/cockpit/yiacad_backend_proof.sh --action run`
## Ce que la preuve vérifie
1. la façade locale YiACAD répond via `status`
2. la façade locale répond via `invoke status`
3. le helper KiCad passe bien par la façade et restitue un payload YiACAD structuré
4. le helper FreeCAD passe bien par la façade et restitue un payload YiACAD structuré
5. les champs canoniques `component`, `surface`, `action`, `execution_mode`, `status`, `severity`, `summary`, `artifacts`, `next_steps` sont présents
## Artefacts produits
- `artifacts/yiacad_backend_proof/<timestamp>/backend_status.json`
- `artifacts/yiacad_backend_proof/<timestamp>/backend_invoke_status.json`
- `artifacts/yiacad_backend_proof/<timestamp>/kicad_transport.json`
- `artifacts/yiacad_backend_proof/<timestamp>/freecad_transport.json`
- `artifacts/yiacad_backend_proof/<timestamp>/summary.json`
- `artifacts/yiacad_backend_proof/<timestamp>/summary.md`
- alias:
- `artifacts/yiacad_backend_proof/latest.json`
- `artifacts/yiacad_backend_proof/latest.md`
## Lecture opérateur
- `status=done` signifie que la preuve de transport et de contrat est bonne
- un payload métier peut rester `blocked` dans la preuve si l’entrée est volontairement invalide; cela ne casse pas la preuve tant que:
- le transport fonctionne,
- le contrat est respecté,
- les artefacts sont produits
## Décision
- cette preuve ne ferme pas `yiacad-fusion`
- le blocage `kicad-host-entrypoint` reste distinct et externe à `Kill_LIFE`
- cette preuve, combinée au reroutage `service-first` de `yiacad_uiux_tui.sh`, ferme `T-ARCH-101C` pour les surfaces actives
- les suites de travail restent suivies séparément dans:
- `T-UX-003` pour les surfaces compilées plus profondes
- `T-UX-004` pour la persistance complète `review center / inspector`
- `T-RE-209` pour le lot opérateur YiACAD complet
## Delta 2026-03-21 - T-UX-006F
- la preuve backend n'utilise plus des chemins `/tmp/nonexistent*` jetables
- elle s'appuie maintenant sur des fixtures stables du repo:
- `tools/cad/proof_fixtures/yiacad_backend_proof/probe_board.kicad_pcb`
- `tools/cad/proof_fixtures/yiacad_backend_proof/probe_model.FCStd`
- le statut metier reste volontairement `blocked` sur `review.bom`, mais le contexte operateur devient stable et traçable
docs/YIACAD_BACKEND_SERVICE_2026-03-21.md
+67
View File
@@ -0,0 +1,67 @@
# YiACAD backend service - 2026-03-21
## Objectif
Remplacer le chemin purement CLI direct par un backend local plus stable et adressable, tout en gardant un fallback direct pour ne pas casser les surfaces deja livrees.
## Livrables
- service local:
- `tools/cad/yiacad_backend_service.py`
- client service-first:
- `tools/cad/yiacad_backend_client.py`
- TUI operatoire:
- `tools/cockpit/yiacad_backend_service_tui.sh`
## Fonctionnement
```mermaid
flowchart LR
UI["KiCad plugin / FreeCAD workbench"] --> Client["yiacad_backend_client.py"]
Client --> Service["yiacad_backend_service.py"]
Client --> Fallback["yiacad_native_ops.py"]
Service --> Native["yiacad_native_ops.py"]
Native --> Backend["yiacad_backend.py"]
Backend --> Artifacts["context.json / uiux_output.json / service artifacts"]
```
## Chemin d'execution
1. la surface appelle `yiacad_backend_client.py`
2. le client tente `service-first`
3. si le service n'est pas disponible, il l'auto-demarre
4. si le service reste indisponible, le client retombe sur `yiacad_native_ops.py`
## Surfaces recablees
- KiCad plugin:
- `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin/yiacad_action.py`
- FreeCAD workbench:
- `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
## Commandes utiles
- statut:
- `bash tools/cockpit/yiacad_backend_service_tui.sh --action status`
- health JSON:
- `bash tools/cockpit/yiacad_backend_service_tui.sh --action health --json`
- logs:
- `bash tools/cockpit/yiacad_backend_service_tui.sh --action logs-summary`
## Artefacts
- `artifacts/cad-ai-native/service/latest_server.json`
- `artifacts/cad-ai-native/service/latest_health.json`
- `artifacts/cad-ai-native/service/latest_response.json`
- `artifacts/cad-ai-native/service/server.log`
## Veille officielle utile
- [Python `urllib.request`](https://docs.python.org/3/library/urllib.request.html)
- [Python `http.server`](https://docs.python.org/3/library/http.server.html)
- [Python `socketserver`](https://docs.python.org/3/library/socketserver.html)
## Etat
- `T-ARCH-101C` est maintenant engage sur les surfaces actives Python.
- le prochain palier restant est l'extension eventuelle du chemin service-first aux surfaces compilees plus profondes.
docs/YIACAD_EXHAUSTIVE_REFOUNTE_AUDIT_2026-03-20.md
+114
View File
@@ -0,0 +1,114 @@
# YiACAD / Kill_LIFE - Audit exhaustif de refonte 2026-03-20
## Synthese executive
Kill_LIFE dispose deja d'une base rarement aussi structuree pour un programme IA-native embarque/CAD: spec-first, plans vivants, lots autonomes, cockpit TUI, traces d'artefacts, forks natifs KiCad/FreeCAD et matrice agentique. Le point faible principal n'est pas l'absence d'outillage mais la multiplication des couches de gouvernance et des deltas documentaires. YiACAD est maintenant suffisamment cable pour quitter la phase "brancher des commandes" et entrer dans la phase "designer l'orchestration utilisateur et fiabiliser le backend natif".
## Points forts
- `specs/00_intake.md` a `specs/04_tasks.md` forment une colonne vertebrale claire.
- `tools/cockpit/` fournit deja une vraie surface de pilotage TUI avec logs et artefacts.
- `docs/plans/12_plan_gestion_des_agents.md`, `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md` et `docs/plans/18_*` donnent une memoire projet operationnelle.
- YiACAD dispose maintenant d'une presence native reelle dans `kicad-ki` et `freecad-ki`, au dela du simple plugin local.
- `tools/cad/yiacad_native_ops.py` fournit un runner CAD commun pour `status`, `ERC/DRC`, `BOM review`, `ECAD/MCAD sync`.
- Le repo couvre plusieurs horizons a la fois: firmware, hardware, CAD, MCP, compliance, mesh tri-repo, ops.
## Points faibles
- La documentation est riche mais tres fragmentee. Beaucoup de fichiers jouent un role voisin: audit, manifeste, plan, delta, handoff, todo, resume hebdomadaire.
- Les sources de verite se chevauchent entre `README.md`, `specs/03_plan.md`, `specs/04_tasks.md`, `docs/plans/18_*`, `docs/plans/20_*`, `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`.
- YiACAD reste hybride: KiCad a deja des points d'insertion compiles, FreeCAD reste surtout au niveau workbench Python, et le backend final reste un runner Python local.
- Les lanes externes `n8n`, MCP, Docker, mesh machines et tri-repo ajoutent de la puissance mais aussi beaucoup de volatilite operationnelle.
- La densite des artefacts et logs augmente plus vite que les surfaces de lecture synthese.
## Opportunites d'amelioration
- Reducer les doublons en designant un "hub canonique de refonte" qui pointe vers les docs detaillees au lieu d'ajouter des deltas partout.
- Faire de `T-UX-004` la prochaine priorite: palette de commandes, review center, inspector persistant, latence et etats explicites.
- Stabiliser le backend YiACAD derriere une API locale unique plutot qu'un simple runner Python expose.
- Uniformiser la logique de contexte projet entre KiCad, FreeCAD et les artefacts CAD.
- Faire remonter les resultats `ERC/DRC`, `BOM review` et `ECAD/MCAD sync` dans une meme couche de restitution UX.
## Evaluation de l'integration IA
### Ce qui est deja bien positionne
- IA comme copilote contextualise et non comme autorite opaque.
- Utilitaires CAD concrets deja exposes dans l'UI native.
- Base MCP deja presente pour brancher davantage d'outils contextuels.
- Trajectoire Apple-native correcte: feedback explicite, surfaces contextualisees, actions reversibles, documents de reference deja produits.
### Ce qui manque encore
- Une couche de synthese IA transversale qui relie schema, PCB, BOM, FCStd, status machine et artefacts.
- Une experience utilisateur persistante pour les revues, recommandations et diffs.
- Une couche backend plus robuste que le simple lancement de script local.
- Des contrats de sortie normalises entre chaque action YiACAD pour une UI plus riche.
### Integrations IA prioritaires
1. `review center` multi-surface pour agreger `ERC/DRC`, BOM, sync et recommandations.
2. `command palette` YiACAD avec actions, recent projects, contexts et suggestions.
3. `context broker` local qui unifie projet KiCad, document FreeCAD, artefacts et etat runtime.
4. `native response cards` dans KiCad/FreeCAD pour afficher resultats, severite, liens artefacts, prochaines actions.
## Audit gouvernance / ops
### Mature aujourd'hui
- `tools/cockpit/refonte_tui.sh`
- `tools/cockpit/yiacad_uiux_tui.sh`
- `tools/cockpit/agent_matrix_tui.sh`
- `tools/cockpit/log_ops.sh`
- `tools/cockpit/render_weekly_refonte_summary.sh`
- `docs/plans/12_plan_gestion_des_agents.md`
- `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
- `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`
### Fragile aujourd'hui
- duplication de deltas dans les plans et TODOs
- visibilite diffuse du "prochain lot canonique"
- fragmentation de la documentation entre audit, runbook, handoff, synthese et README
- lisibilite inegale des logs quand plusieurs lanes tournent en parallele
## Recommandation de priorisation
```mermaid
flowchart TD
A["Fondation deja solide"] --> B["T-UX-004: command palette"]
A --> C["T-UX-004: review center"]
A --> D["T-UX-004: inspector persistant"]
B --> E["Context broker local YiACAD"]
C --> E
D --> E
E --> F["Backend YiACAD plus robuste que le runner Python"]
F --> G["UX unifiee KiCad + FreeCAD + artefacts"]
A --> H["Consolider les sources de verite docs/plans/todos"]
H --> G
```
## Cartographie rapide des zones
| Zone | Etat actuel | Lecture |
| --- | --- | --- |
| `tools/cockpit/` | fort | couche ops deja tres exploitable |
| `specs/` | fort | colonne vertebrale projet claire |
| `docs/plans/` | moyen | riche mais diffuse |
| `tools/cad/` | moyen/fort | runner YiACAD utile, prochaine marche backend |
| `.runtime-home/cad-ai-native-forks/` | moyen | insertion native engagee mais encore heterogene |
| `tools/ai/` | moyen | interessant mais volatilite runtime plus elevee |
| `artifacts/` | moyen | riche, besoin de lecture plus synthese |
## Sources externes utiles
- [Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)
- [Human Interface Guidelines for Generative AI](https://developer.apple.com/design/human-interface-guidelines/generative-ai)
- [What’s new - Design - Apple Developer](https://developer.apple.com/design/whats-new/)
- [App Intents](https://developer.apple.com/documentation/AppIntents)
- [KiCad source mirror](https://github.com/KiCad/kicad-source-mirror)
- [FreeCAD](https://github.com/FreeCAD/FreeCAD)
- [KiCad StepUp](https://github.com/easyw/kicadStepUpMod)
- [CadQuery](https://github.com/CadQuery/cadquery)
- [CQ-editor](https://github.com/CadQuery/CQ-editor)
- [kicad-mcp](https://github.com/lamaalrajih/kicad-mcp)
docs/YIACAD_GIT_EDA_PLATFORM_2026-03-22.md
+76
View File
@@ -0,0 +1,76 @@
# YiACAD Git EDA platform - 2026-03-22
## Scope
Translate the Git-first SaaS architecture into an actual repo slice that can grow incrementally:
- `web/` for the product surface
- GraphQL as the HTTP aggregation boundary
- a separate Yjs websocket lane for collaboration
- Git-tracked `.excalidraw` files inside the project tree
## Implemented scaffold
- `web/app/` now exposes four surfaces:
- `/`
- `/diagram`
- `/pcb`
- `/review`
- `web/app/api/graphql/route.ts` is the API gateway entry
- `web/app/api/project-files/[...segments]/route.ts` serves Git-backed project files to browser viewers
- `web/lib/project-store.ts` is the local project service and diagram service seed
- `web/realtime/server.mjs` starts the dedicated Yjs websocket server with persistence
## Stored project shape
```text
web/project/
├── diagrams/
│ ├── system.excalidraw
│ └── power.excalidraw
├── pcb/
│ └── README.md
└── .ci/
├── queue.json
├── artifacts.json
└── pull-requests.json
```
## Why this shape
- `.excalidraw` remains plain JSON, so Git diff and PR review stay cheap
- KiCad files remain canonical and are only projected into API/view models
- CI outputs and review state have their own lane under `.ci/` instead of mutating source files
## Product surface map
### Dashboard
- project files
- PR list
- CI runs
- artifact counts
### Diagram editor
- Excalidraw canvas
- Git-backed save
- local queue trigger for KiBot and KiCad headless
### PCB viewer
- KiCanvas lane
- artifact summary
### PR review
- KiCad diff placeholder
- Excalidraw diff placeholder
- artifact preview readiness
## Next hard problems
- bind Excalidraw scene state into Yjs without creating a second source of truth
- add a real queue backend instead of a local JSON queue stub
- add a real worker/orchestrator contract for KiCad CLI, KiBot, KiAuto, Gerber, STEP, BOM, PDF
- replace placeholder PR/artifact JSON with outputs derived from real Git and CI state
docs/YIACAD_GLOBAL_AI_INTEGRATION_ASSESSMENT_2026-03-20.md
+62
View File
@@ -0,0 +1,62 @@
# Evaluation des integrations IA - YiACAD / Kill_LIFE (2026-03-20)
## Principe directeur
L'IA doit rester une couche d'acceleration, de lecture et d'orchestration, jamais la source d'autorite. Le projet dispose deja des briques necessaires; le gain principal vient maintenant de leur coordination et de la reduction du cout d'usage.
## Matrice priorisee
| Surface | Integration IA prioritaire | Gain attendu | Garde-fou | Priorite |
| --- | --- | --- | --- | --- |
| Specs, plans, TODOs | Resume structure, triage de lots, handoff automatique | Meilleure continuite, moins de perte de contexte | Toujours adosser aux specs et au manifeste | P0 |
| YiACAD native shells | Actions contextualisees `Status`, `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync` | Valeur immediate pour ECAD/MCAD | Resultats auditables, jamais d'auto-apply opaque | P0 |
| Review center | Regroupement IA des findings CAD, docs et backlog | UX plus lisible, moins de dispersion | Les commandes restent explicites et annulables | P0 |
| MCP runtime | Orchestration et lecture de sante des serveurs CAD/knowledge/github | Deblocage rapide et meilleure observabilite | Contrat `ready|degraded|blocked` conserve | P1 |
| Docs et evidence | Synthese de drift, de coherence README/docs/plans | Dette documentaire reduite | Validation humaine + liens sources | P1 |
| Firmware / hardware review | Assistance de lecture, tri de warnings, preparation de revues | Gain de temps en revue technique | Mode propose-only | P1 |
| ZeroClaw / mesh ops | Aide au diagnostic et a la priorisation cross-repo | Coordination plus stable | Sorties structurees et journalisees | P2 |
## Architecture IA recommandee
```mermaid
flowchart LR
User["Operateur / agent"] --> TUI["TUI refonte YiACAD"]
TUI --> Planner["Specs + plans + TODOs"]
TUI --> Native["KiCad / FreeCAD native shells"]
TUI --> MCP["MCP runtime status"]
Native --> Backend["YiACAD backend service"]
Backend --> Ops["yiacad_native_ops / adapters"]
Planner --> Evidence["docs + artifacts + logs"]
MCP --> Evidence
Ops --> Evidence
```
## Briques externes pertinentes
- [KiCad upstream](https://github.com/KiCad/kicad-source-mirror): base ECAD canonique, active, multi-surface.
- [FreeCAD upstream](https://github.com/FreeCAD/FreeCAD): base MCAD parametrique canonique.
- [kicadStepUp](https://github.com/easyw/kicadStepUpMod): pont ECAD/MCAD pratique pour l'alignement FreeCAD/KiCad.
- [CadQuery](https://github.com/CadQuery/cadquery): moteur de CAD scriptable, utile pour scenarios generatifs et parametrisation.
- [kicad-mcp](https://github.com/lamaalrajih/kicad-mcp): exposition MCP utile pour automatisation et contextualisation.
- [freecad-mcp](https://github.com/contextform/freecad-mcp): meme logique cote FreeCAD.
## Recommandations d'integration
### P0
- Garder les shells natifs comme surfaces visibles.
- Faire emerger un backend YiACAD stable entre les shells et `yiacad_native_ops.py`.
- Ajouter une palette de commandes commune et un review center multi-surface.
### P1
- Standardiser le format de sortie IA pour specs, docs et CAD reviews.
- Mutualiser les artefacts de resultat afin d'eviter les differences entre KiCad, FreeCAD et TUI.
### P2
- Explorer une IA plus proactive pour planning et reporting inter-repo, une fois la couche backend YiACAD stabilisee.
## Conclusion
Le projet n'a pas besoin de "plus d'IA" en premier. Il a besoin d'une IA mieux concentree, mieux exposee et plus uniforme entre shells natifs, TUI, plans et evidence packs.
docs/YIACAD_GLOBAL_FEATURE_MAP_2026-03-20.md
+66
View File
@@ -0,0 +1,66 @@
# YiACAD global feature map (2026-03-20)
## Carte Mermaid
```mermaid
flowchart TD
Core["Kill_LIFE core"] --> Specs["specs/"]
Core --> Docs["docs/"]
Core --> Tools["tools/"]
Core --> Artifacts["artifacts/"]
Tools --> Cockpit["cockpit / TUI"]
Tools --> CAD["tools/cad"]
Tools --> MCP["MCP runtime"]
Tools --> AI["tools/ai"]
CAD --> YiACAD["YiACAD lane"]
YiACAD --> NativeKiCad["KiCad native shells"]
YiACAD --> NativeFreeCAD["FreeCAD native workbench"]
YiACAD --> Runner["yiacad_native_ops.py"]
Runner --> Outputs["CAD artifacts + summaries"]
Cockpit --> Plans["plans + todos"]
Docs --> Audit["global audit + AI assessment"]
Docs --> UX["UI/UX Apple-native bundle"]
MCP --> Knowledge["knowledge / github / openscad / freecad / kicad"]
AI --> ZeroClaw["ZeroClaw integrations"]
AI --> Mesh["mesh tri-repo"]
Outputs --> Artifacts
Plans --> Artifacts
```
## Cartes de fonctionnalites
### 1. Gouvernance
- Manifeste de refonte
- Plans vivants
- TODOs prioritaires
- Matrice agents / write-sets
### 2. Pilotage operateur
- Cockpit de refonte
- TUI YiACAD UI/UX
- TUI globale YiACAD
- Resume hebdomadaire
- Politique logs / purge
### 3. CAD IA-native
- Fusion KiCad + FreeCAD
- Hooks natifs dans `kicad manager`, `pcbnew`, `eeschema`
- Workbench FreeCAD YiACAD
- Utilities `status`, `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`
### 4. IA et orchestration
- Runtime MCP
- ZeroClaw integrations
- Patterns LangGraph / AutoGen
- Knowledge base / GitHub dispatch
### 5. Compliance et evidence
- Evidence packs
- Badges
- Validation spec / repo / compliance
- Historisation des lots et de leurs artefacts
docs/YIACAD_GLOBAL_OSS_RESEARCH_2026-03-20.md
+55
View File
@@ -0,0 +1,55 @@
# Recherche web OSS - YiACAD refonte globale (2026-03-20)
## Objectif
Identifier les projets et bibliotheques open source les plus pertinents pour la fusion `KiCad + FreeCAD` et pour la couche IA-native associee.
## References prioritaires
| Projet | Type | Interet pour YiACAD | Source |
| --- | --- | --- | --- |
| KiCad | Upstream ECAD | Base canonique pour `kicad manager`, `pcbnew`, `eeschema` et scripting Python | [KiCad/kicad-source-mirror](https://github.com/KiCad/kicad-source-mirror) |
| FreeCAD | Upstream MCAD | Base canonique pour workbench, docks, documents parametriques et automatisation | [FreeCAD/FreeCAD](https://github.com/FreeCAD/FreeCAD) |
| kicadStepUp | Pont ECAD/MCAD | Reconciliation pratique KiCad <-> FreeCAD, utile pour `ECAD/MCAD Sync` | [easyw/kicadStepUpMod](https://github.com/easyw/kicadStepUpMod) |
| CadQuery | CAD scriptable | Parametrisation geometrique, automation et futurs workflows generatifs | [CadQuery/cadquery](https://github.com/CadQuery/cadquery) |
| kicad-mcp | Serveur MCP | Automation, contextualisation et outillage IA pour KiCad | [lamaalrajih/kicad-mcp](https://github.com/lamaalrajih/kicad-mcp) |
| freecad-mcp | Serveur MCP | Equivalent FreeCAD pour orchestration IA et automation | [contextform/freecad-mcp](https://github.com/contextform/freecad-mcp) |
| LibrePCB | Alternative ECAD | Bon point de comparaison UX/EDA, mais moins aligne sur la trajectoire KiCad + FreeCAD | [LibrePCB/LibrePCB](https://github.com/LibrePCB/LibrePCB) |
## Lecture utile
### KiCad
- L'upstream GitHub est un miroir actif de la branche de developpement KiCad.
- La page upstream affiche une release `10.0.0` marquee `Latest` au 20 mars 2026, ce qui confirme que la base locale doit rester pensee comme evolutive et non figee.
### FreeCAD
- FreeCAD reste la base MCAD parametrique ouverte la plus coherente pour un workbench YiACAD, particulierement pour docks, automatisation Python et echanges STEP.
### StepUp
- `kicadStepUp` est l'outil le plus directement utile quand il s'agit de rapprocher ECAD et MCAD sans reinventer le flux d'echange.
### MCP servers
- `kicad-mcp` et `freecad-mcp` montrent qu'une couche MCP ouverte et locale est deja plausible pour les deux mondes; c'est un bon argument pour formaliser un backend YiACAD proprement separable.
## Recommandations
### A utiliser maintenant
- KiCad upstream
- FreeCAD upstream
- kicadStepUp
- kicad-mcp
- freecad-mcp
### A exploiter ensuite
- CadQuery pour la parametrisation et les futures fonctions generatives
- LibrePCB comme point de comparaison UX et simplification, pas comme base de fusion principale
## Conclusion
Le meilleur axe reste celui deja engage: partir des upstreams `KiCad + FreeCAD`, s'appuyer sur `kicadStepUp` pour le trait d'union ECAD/MCAD, et faire converger les shells natifs avec une couche backend YiACAD puis des integrations MCP bien bornees.
docs/YIACAD_GLOBAL_REFACTOR_AUDIT_2026-03-20.md
+72
View File
@@ -0,0 +1,72 @@
# Audit global YiACAD / Kill_LIFE - refonte exhaustive (2026-03-20)
## Resume executif
`Kill_LIFE` dispose deja d'une colonne vertebrale forte: structure spec-first, cockpit outille, evidence packs, plans vivants, lane CAD IA-native et nombreux scripts d'orchestration. Le point faible principal n'est plus l'absence d'outillage mais la densite du systeme: plusieurs couches coexistent (`Kill_LIFE`, `ai-agentic-embedded-base`, `zeroclaw`, forks CAD, MCP runtime, mesh tri-repo), ce qui augmente le cout de lecture, de priorisation et d'alignement.
YiACAD progresse bien sur les surfaces natives KiCad/FreeCAD, mais le projet reste partiellement fragmente entre shell natif, runner Python local, TUI de coordination, docs historisees par deltas et sous-repos voisins.
## 1. Points forts structurels
- Separation nette des grandes surfaces dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/artifacts`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/firmware`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/hardware`.
- Gouvernance deja explicite dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/REFACTOR_MANIFEST_2026-03-20.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs/03_plan.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/specs/04_tasks.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/plans/12_plan_gestion_des_agents.md`.
- Couverture outillage forte dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/hw`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/ai`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/compliance`, avec conventions de logs deja presentes.
- Cadre YiACAD deja bien pose dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/CAD_AI_NATIVE_FORK_STRATEGY.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/.runtime-home/cad-ai-native-forks`.
- Documentation operatoire riche dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/README.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/index.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/RUNBOOK.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/QUICKSTART.md`.
## 2. Points faibles et risques majeurs
- Superposition de plusieurs coeurs de projet: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/ai-agentic-embedded-base`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/zeroclaw`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/openclaw`, ce qui rend la frontiere canonique moins evidente.
- Multiplication des points d'entree TUI/cockpit dans `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit` et `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/tui`; l'operateur doit encore connaitre plusieurs scripts pour couvrir un meme lot.
- Dette de cohesion documentaire: de nombreux documents sont bons individuellement, mais la navigation depend encore beaucoup d'ajouts chronologiques et de memorisation implicite.
- Couche YiACAD encore basee sur un runner Python local (`/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad/yiacad_native_ops.py`) plutot que sur un backend embarque plus robuste.
- `artifacts/*` est riche mais volumineux; sans resume plus agressif et politique de retention centralisee, le bruit operationnel va augmenter.
- Les forks natifs sous `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/.runtime-home/cad-ai-native-forks` ameliorent l'experience, mais introduisent un couplage supplementaire avec le repo principal.
## 3. Opportunites d'amelioration immediates
- Unifier la refonte globale dans une TUI dediee, orientee audit/spec/plan/todo/research/logs, pour eviter de disperser la navigation entre plusieurs scripts.
- Introduire une architecture backend YiACAD explicite: `native shell -> stable service API -> native ops`, au lieu de faire porter la coordination au seul runner Python local.
- Consolider une matrice de proprietaires par write-set pour les zones les plus sensibles: forks CAD, docs canoniques, cockpit, mesh tri-repo, runtime MCP.
- Reduire la surface cognitive du repo principal en clarifiant le statut de `ai-agentic-embedded-base`, `zeroclaw` et `openclaw`: source canonique, dependance, ou sous-projet orchestre.
- Centraliser les cartes de fonctionnalites et audits de refonte sous un bundle unique YiACAD global afin de limiter les documents paralleles a faible discoverabilite.
## 4. Zones deja matures
- Cockpit et orchestration: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit`.
- Gouvernance refonte et agentique: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/REFACTOR_MANIFEST_2026-03-20.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/plans/12_plan_gestion_des_agents.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`.
- Documentation YiACAD UI/UX et CAD native: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`.
- Utilities CAD IA-native: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad/yiacad_fusion_lot.sh`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cad/yiacad_native_ops.py`.
- Support MCP et smoke tooling: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/freecad_mcp.py`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/openscad_mcp.py`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/github_dispatch_mcp.py`, `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/knowledge_base_mcp.py`.
## 5. Zones encore fragmentees
- Refonte globale versus refonte UI/UX: beaucoup d'elements existent, mais la couche "audit global + lot suivant" n'etait pas encore assemblee en bundle unique.
- Ia-native CAD versus backend profond: les shells natifs existent, mais la couche metier reste decentralisee entre runner, scripts, artifacts et conventions de contexte projet.
- Tri-repo mesh et ZeroClaw: l'intention est documentee, mais la lisibilite operateur reste inferieure a celle de la lane YiACAD.
- README, manifestes, plans et TODOs sont riches mais demandent encore une discipline forte de convergence pour eviter les cartes paralleles.
## 6. Priorites recommandees
### P0
- Ouvrir un lot global de refonte YiACAD avec cockpit dedie, spec, plan, todo, audit et recherche centralises.
- Formaliser le prochain palier backend YiACAD afin de sortir du simple runner Python local.
- Stabiliser le lien entre refonte globale et `T-UX-004` pour que la command palette, le review center et l'inspector persistant deviennent le prochain objectif UX.
### P1
- Rationaliser les points d'entree TUI par domaine.
- Reduire la dette d'indexation documentaire via README + docs/index + TUI.
- Clarifier le statut fonctionnel de chaque sous-repo majeur.
### P2
- Remonter progressivement les integrations YiACAD vers un service plus embarque.
- Ajouter une lecture de maturite par lane avec KPI et resumés d'etat stables.
## 7. Lecture courte priorisee
1. La structure est solide.
2. La complexite vient surtout de l'empilement des couches et du nombre d'entrees.
3. La meilleure amelioration immediate est une couche de pilotage global YiACAD qui unifie audit, plans, recherche, feature map et logs.
docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md
+169
View File
@@ -0,0 +1,169 @@
# YiACAD Native UI Insertion Points - 2026-03-20
## Objectif
Consolider les points d’insertion natifs les plus sûrs pour faire monter YiACAD du niveau `plugin/workbench Python` vers un shell compilé et persistant dans les forks `kicad-ki` et `freecad-ki`.
## KiCad - points d’insertion recommandés
### Menus
- `EDA_BASE_FRAME::doReCreateMenuBar()` et ses déclinaisons par frame.
- Ancrages principaux:
- `common/eda_base_frame.cpp`
- `kicad/menubar.cpp`
- `pcbnew/menubar_pcb_editor.cpp`
- `eeschema/menubar.cpp`
### Toolbar
- `configureToolbars()` et les factories de contrôles custom.
- Ancrages principaux:
- `include/eda_base_frame.h`
- `common/eda_base_frame.cpp`
- `common/eda_draw_frame.cpp`
- `pcbnew/toolbars_pcb_editor.cpp`
- `eeschema/toolbars_sch_editor.cpp`
- décision `T-UX-003`:
- `common/eda_base_frame.cpp` reste `no-touch` pour ce lot;
- la surface canonique est editor-locale: `toolbars_*` + `*_editor_control.*`;
- raison: `EDA_BASE_FRAME` est partagé, `configureToolbars()` y est générique, et la recréation de menu macOS y est déjà sensible.
### Inspector / panneau assistant
- utiliser un `AssistantPane` dockable parallèle au panneau propriétés, pas imbriqué dedans;
- ancrages:
- `pcbnew/pcb_edit_frame.cpp`
- `eeschema/sch_edit_frame.cpp`
- `common/widgets/properties_panel.h`
### Commandes IA
- surface native recommandée: `TOOL_ACTION` + `ACTION_MENU` + boutons toolbar;
- panneau riche recommandé: `WEBVIEW_PANEL`;
- ancrages:
- `include/tool/tool_action.h`
- `include/tool/action_menu.h`
- `include/widgets/webview_panel.h`
- `common/widgets/webview_panel.cpp`
### Risques majeurs
- couplage fort à la persistance AUI/layout;
- recréation de menu macOS déjà différée et sensible;
- forte dépendance métier des panneaux propriétés PCB/SCH;
- extension plus fragile côté `pcbnew` à cause du mélange API/IPC/legacy Python.
## FreeCAD - points d’insertion recommandés
### Workbench natif
- workbench `YiACADWorkbench` comme point d’entrée stable;
- chaîne native:
- `src/Mod/YiACADWorkbench/InitGui.py`
- `src/Gui/FreeCADGuiInit.py`
- `src/Gui/Application.cpp`
- `src/Gui/Workbench.cpp`
### Menus / toolbars globaux
- injecter globalement par workbench manipulator, pas via patchs locaux dispersés;
- ancrages:
- `src/Gui/ApplicationPy.cpp`
- `src/Gui/WorkbenchManipulator.h`
- `src/Gui/WorkbenchManipulatorPython.cpp`
### Inspector / dock natif
- point d’entrée natif: `MainWindow` + `DockWindowManager`;
- recommandation: un seul `YiACAD Inspector` à droite, réutilisant la logique `ComboView`;
- ancrages:
- `src/Gui/MainWindow.cpp`
- `src/Gui/DockWindow.h`
- `src/Gui/DockWindowManager.cpp`
- `src/Gui/ComboView.h`
- `src/Gui/ComboView.cpp`
- `src/Gui/PropertyView.h`
- décision `T-UX-003` / `T-UX-004`:
- write-set sûr immédiat: `src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`;
- plus petit write-set shell compilé défendable: `src/Gui/MainWindow.cpp` seul;
- `DockWindowManager.cpp` et `ComboView.cpp` restent `no-touch` tant qu’un besoin shell démontré n’impose pas plus.
### Commandes IA
- commandes conservées en Python via `FreeCADGui.addCommand` tant que le chrome n’est pas remonté en C++;
- ancrages:
- `src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- `src/Gui/Command.cpp`
### Risques majeurs
- menus/toolbars reconstruits à chaque changement de workbench;
- persistance de layout sensible aux noms des docks et toolbars;
- manipulator Python insuffisant pour remodeler proprement les docks;
- tabification des docks appliquée une fois, donc fragile si le design dérive.
## Décision d’architecture
```mermaid
flowchart LR
KiCad["KiCad shell natif"] --> Assistant["AssistantPane / Inspector"]
FreeCAD["FreeCAD shell natif"] --> Inspector["YiACAD Inspector"]
Assistant --> Actions["review / sync / explain"]
Inspector --> Actions
Actions --> NativeOps["tools/cad/yiacad_native_ops.py"]
NativeOps --> Artifacts["artifacts/cad-ai-native"]
```
## Priorité d’implémentation
1. KiCad: `kicad_manager` puis `pcbnew` et `eeschema`
2. FreeCAD: `YiACADWorkbench` puis `MainWindow`/`DockWindowManager`
3. Réplication secondaire: footprint editor, symbol editor, raffinements de toolbar et palette
## Delta 2026-03-20 - surfaces maintenant branchées
- `kicad/kicad_manager_*`: action native `YiACAD Status` déjà branchée.
- `pcbnew/tools/board_editor_control.*`: handler `YiACAD Status` ajouté et exposé dans `pcbnew/menubar_pcb_editor.cpp` et `pcbnew/toolbars_pcb_editor.cpp`.
- `eeschema/tools/sch_editor_control.*`: handler `YiACAD Status` ajouté et exposé dans `eeschema/menubar.cpp` et `eeschema/toolbars_sch_editor.cpp`.
- `freecad-ki/src/Mod/YiACADWorkbench/*`: `YiACAD Inspector` dockable disponible comme première surface native de travail.
- Prochain remplacement prévu: suppression du bridge local au profit d'un backend YiACAD directement adressable par les shells natifs.
## Delta 2026-03-20 - direct runner integration
- `kicad/kicad_manager_*`: les actions YiACAD passent maintenant directement par `tools/cad/yiacad_native_ops.py`.
- `pcbnew/tools/board_editor_control.*`: `Status`, `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync` appellent directement le runner natif YiACAD.
- `eeschema/tools/sch_editor_control.*`: même recâblage direct vers le runner natif YiACAD.
- `freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`: chargement direct en mémoire de `yiacad_native_ops.py` via `importlib`.
- Le prochain point d'insertion critique devient la couche de retour UX persistante plutôt que la simple exécution de commandes.
## Delta 2026-03-20 18:18 - garde-fous shell KiCad
- `EDA_BASE_FRAME` est explicitement sorti du write-set `T-UX-003`.
- write-set minimal retenu côté KiCad:
- `pcbnew/toolbars_pcb_editor.cpp`
- `pcbnew/tools/board_editor_control.*`
- `eeschema/toolbars_sch_editor.cpp`
- `eeschema/tools/sch_editor_control.*`
- risque explicite:
- les runners shell PCB/SCH restent synchrones (`wxExecute(..., wxEXEC_SYNC)` + `wxMessageBox`) et peuvent geler l’UI;
- le comportement shell est dupliqué entre PCB et SCH, donc toute extension doit rester strictement symétrique.
## Delta 2026-03-20 18:20 - garde-fous shell FreeCAD
- write-set sûr retenu:
- `freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- plus petit write-set shell compilé admissible à la prochaine tranche:
- `freecad-ki/src/Gui/MainWindow.cpp`
- surfaces explicitement hors write-set pour l’instant:
- `freecad-ki/src/Gui/DockWindowManager.cpp`
- `freecad-ki/src/Gui/ComboView.cpp`
- risque explicite:
- double ownership du dock si le workbench Python et un dock shell `Std_YiACADView` coexistent;
- persistance de layout cassée si le nom du dock diverge;
- `run_native_action()` reste synchrone dans le thread UI et amplifierait les freezes si on remonte trop vite en shell global.
## Delta 2026-03-20 23:06 - T-UX-003D shell anchor
- `MainWindow.cpp` porte maintenant un premier ancrage shell compilé `Std_YiACADShellView`.
- Le dock reste cache par défaut pour éviter une double autorité avec l’inspector workbench Python.
- Ce palier ne touche ni `DockWindowManager.cpp` ni `ComboView.cpp`; il sert uniquement de point d’entrée shell stable pour les prochaines cartes résultat YiACAD.
## Delta 2026-03-20 23:22 - shell card scaffold
- L’ancrage `Std_YiACADShellView` expose maintenant une première carte shell lisible avec les rubriques du contrat YiACAD: `surface`, `status`, `severity`, `summary`, `artifacts`, `next_steps`.
- Le toggle d’affichage du dock est nommé explicitement `YiACAD Shell`, ce qui le rend pilotable depuis les menus de docks sans nouvelle logique dans `DockWindowManager.cpp`.
docs/YIACAD_OPERATOR_INDEX_2026-03-21.md
+55
View File
@@ -0,0 +1,55 @@
# YiACAD Operator Index - 2026-03-21
## Objectif
Fournir un point d’entrée opérateur unique pour ne plus demander à l’utilisateur de choisir implicitement entre la lane UI/UX (`20`), la refonte globale (`21`) et le backend service YiACAD.
## Entrée canonique
- commande: `bash tools/cockpit/yiacad_operator_index.sh --action status`
## Routage
| Besoin | Commande | Lane |
| --- | --- | --- |
| Vue opérateur courte | `bash tools/cockpit/yiacad_operator_index.sh --action status` | index |
| État UI/UX produit | `bash tools/cockpit/yiacad_operator_index.sh --action uiux` | `20` |
| État refonte globale | `bash tools/cockpit/yiacad_operator_index.sh --action global` | `21` |
| Backend service | `bash tools/cockpit/yiacad_operator_index.sh --action backend` | index |
| Contexte de revue compact | `bash tools/cockpit/yiacad_operator_index.sh --action review-context` | index |
| Preuves et docs | `bash tools/cockpit/yiacad_operator_index.sh --action proofs` | index |
| Logs de l’index | `bash tools/cockpit/yiacad_operator_index.sh --action logs-summary --json` | index |
## Décision
- `yiacad_uiux_tui.sh` reste la surface produit et shell/native.
- `yiacad_refonte_tui.sh` reste la surface audit/global/backend.
- `yiacad_backend_service_tui.sh` devient la vue canonique du backend service YiACAD.
- `yiacad_operator_index.sh` devient l’entrée opérateur stable.
## Lots raccordés
- produit: `T-UX-004`
- architecture: `T-ARCH-101C`
- ops: `T-OPS-118`
- session persistante: `T-UX-006`
- contexte compact: `T-UX-006D`
## Preuves
- `tools/cockpit/yiacad_operator_index.sh`
- `tools/cockpit/yiacad_uiux_tui.sh`
- `tools/cockpit/yiacad_refonte_tui.sh`
- `tools/cockpit/yiacad_backend_service_tui.sh`
- `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`
- `docs/plans/21_plan_refonte_globale_yiacad.md`
## Delta 2026-03-21 - review context
- nouvelle route opérateur:
- `bash tools/cockpit/yiacad_operator_index.sh --action review-context`
- cette vue condense:
- session courante
- taxonomie
- trail récent
- prochaines étapes
docs/YIACAD_OPERATOR_LOG_CONTRACT_2026-03-21.md
+24
View File
@@ -0,0 +1,24 @@
# YiACAD operator log contract - 2026-03-21
## Canonical entries
- Operator index: `bash tools/cockpit/yiacad_operator_index.sh --action status`
- Logs lane: `bash tools/cockpit/yiacad_logs_tui.sh --action status`
- Proofs lane: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`
## Log sources
- `artifacts/yiacad_operator_index`
- `artifacts/yiacad_uiux_tui`
- `artifacts/yiacad_backend_service_tui`
- `artifacts/yiacad_proofs_tui`
- `artifacts/cad-ai-native/service`
## Actions
- `bash tools/cockpit/yiacad_logs_tui.sh --action summary`
- `bash tools/cockpit/yiacad_logs_tui.sh --action list`
- `bash tools/cockpit/yiacad_logs_tui.sh --action latest`
- `bash tools/cockpit/yiacad_logs_tui.sh --action purge-logs --days 14 --yes`
## Intent
- Keep one public entry for operators.
- Separate logs and proofs into dedicated surfaces.
- Preserve historical aliases until the next cleanup lot.
docs/YIACAD_PROOFS_TUI_2026-03-21.md
+34
View File
@@ -0,0 +1,34 @@
# YiACAD proofs TUI - 2026-03-21
## Intent
- Provide a canonical proof surface without breaking historical operator aliases.
- Centralize proof-oriented actions and log hygiene in a dedicated TUI.
- Keep the change isolated in new files because the codebase is shared.
## Canonical entry
- `bash tools/cockpit/yiacad_proofs_tui.sh --action status`
## Actions
- `status`
- `backend`
- `review-session`
- `review-history`
- `review-taxonomy`
- `logs-summary`
- `logs-list`
- `logs-latest`
- `purge-logs --days 14 --yes`
## Routing
```mermaid
flowchart TD
A["yiacad_proofs_tui.sh"] --> B["yiacad_backend_proof.sh --action run"]
A --> C["yiacad_uiux_tui.sh --action review-session"]
A --> D["yiacad_uiux_tui.sh --action review-history"]
A --> E["yiacad_uiux_tui.sh --action review-taxonomy"]
```
## Notes
- This lot does not remove aliases yet.
- This lot prepares a safer follow-up cleanup by giving operators a single proofs entry.
- No execution validation was run in this pass.
docs/YIACAD_REVIEW_SESSION_2026-03-21.md
+102
View File
@@ -0,0 +1,102 @@
# YiACAD Review Session - 2026-03-21
## Objectif
Poser la première tranche de `T-UX-006`:
- persister la dernière session de revue YiACAD
- la réafficher dans les surfaces Python déjà YiACAD
- la rendre lisible depuis la TUI sans ouvrir les GUI
## Canon
- artefact de session:
- `artifacts/cad-ai-native/latest_review_session.json`
- artefact d'historique:
- `artifacts/cad-ai-native/review_history.json`
- lecture TUI:
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-session`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-history`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-taxonomy`
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-context`
## Ce qui est persistant
- le dernier payload YiACAD structuré reçu par:
- le plugin KiCad YiACAD
- le workbench FreeCAD YiACAD
- la persistance reste additive:
- aucun changement de contrat `yiacad_uiux_output`
- aucune dépendance à une GUI ouverte
- une taxonomie légère est maintenant calculée à partir de l'action:
- `review`
- `analysis`
- `sync`
- `status`
- `artifacts`
## Sources officielles utilisées
- Apple Human Interface Guidelines:
- Human Interface Guidelines: https://developer.apple.com/design/human-interface-guidelines/
- Designing for macOS: https://developer.apple.com/design/human-interface-guidelines/designing-for-macos
- Qt Widgets:
- QMainWindow / saveState / restoreState: https://doc.qt.io/qt-6.8/qmainwindow.html
- Restoring a Window's Geometry: https://doc.qt.io/qt-6/restoring-geometry.html
## Lecture courte
- la doc Apple recommande de supporter la personnalisation des fenêtres et des vues sous macOS
- Qt documente explicitement la sauvegarde/restauration de l’état des docks et fenêtres
- sur cette tranche, on ne touche pas encore au shell compilé profond:
- on pose d’abord la persistance de session au niveau des helpers Python déjà stables
## Décision
- `T-UX-006` démarre par la persistance de session, pas par un refactoring profond des docks compilés
- la suite naturelle est:
- remonter cette session persistante dans les shells compilés quand le write-set sera acceptable
- enrichir l’inspector persistant avec taxonomie et historique de revue
## Delta 2026-03-21 - T-UX-006D
- le contexte de revue compact est maintenant lisible dans les trois surfaces opératoires déjà ouvertes:
- bandeau + contexte récent enrichi dans le plugin KiCad
- trail enrichi avec taxonomie dans le workbench FreeCAD
- vue opérateur compacte via `review-context` dans la TUI et l’index opérateur
- cette tranche garde le write-set strictement sur les surfaces Python et TUI déjà stabilisées
- la suite naturelle devient:
- enrichir encore la lecture multi-vues si besoin
- propager seulement plus tard vers les shells compilés profonds
## Delta 2026-03-21 - T-UX-006E
- `context_ref` retombe maintenant sur un contexte demandé exploitable même quand les fichiers de preuve n'existent pas encore:
- exemple de preuve: `project:tmp/nonexistent`
- le backend service local a ete relance pour recharger le builder de contexte courant
- la vue `review-context` n'est plus polluee par un header `unknown`, tout en gardant le statut metier `blocked` quand l'entree de preuve reste volontairement invalide
## Delta 2026-03-21 - T-UX-006F
- la preuve utilise maintenant des fixtures de repo stables plutot que des chemins temporaires hors repo
- le `context_ref` recent attendu devient de la forme:
- `project:yiacad_backend_proof/probe_board`
- ou `project:yiacad_backend_proof/probe_model`
- la lecture operateur garde donc un contexte plus utile et reproductible
## Delta 2026-03-21 - T-UX-006D contexte de revue
- le review center YiACAD synthétise maintenant un contexte court lisible:
- session courante
- taxonomie cumulée
- trail récent
- prochaines étapes dédupliquées
- les surfaces Python KiCad et FreeCAD réinjectent ce contexte directement dans leur rendu texte, sans ouvrir les hotspots compilés.
- nouvelle route TUI opérateur:
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-context`
- `bash tools/cockpit/yiacad_operator_index.sh --action review-context`
- repères officiels réutilisés:
- Apple HIG: https://developer.apple.com/design/human-interface-guidelines/
- Designing for macOS: https://developer.apple.com/design/human-interface-guidelines/designing-for-macos
- Qt `QMainWindow`: https://doc.qt.io/qt-6.8/qmainwindow.html
- Qt restoring geometry/state: https://doc.qt.io/qt-6/restoring-geometry.html
docs/YIACAD_TUX004_FEATURE_MAP_2026-03-20.md
+33
View File
@@ -0,0 +1,33 @@
# YiACAD T-UX-004 - Feature map
```mermaid
mindmap
root((YiACAD T-UX-004))
Palette
Status
ERC/DRC
BOM Review
ECAD/MCAD Sync
Open Artifacts
Review Center
Severity
Summary
Artifact Links
Next Steps
Cross-surface context
Inspector
Persistent panel
Project context
Last run
AI hints
Context Broker
KiCad project path
FreeCAD document path
Artifact lineage
Runtime status
UX Contracts
done/degraded/blocked
latency state
non-AI fallback
deterministic outputs
```
docs/YIACAD_UIUX_OUTPUT_CONTRACT_2026-03-20.md
+68
View File
@@ -0,0 +1,68 @@
# YiACAD UI/UX Output Contract - 2026-03-20
## Objectif
Normaliser la restitution des actions YiACAD pour que KiCad, FreeCAD, les TUI et les artefacts lisent tous la meme forme de resultat, sans parser un texte libre.
## Canon
- schema: `specs/contracts/yiacad_uiux_output.schema.json`
- exemple: `specs/contracts/examples/yiacad_uiux_output.example.json`
- lot source: `T-UX-004B`
## Champs obligatoires
| Champ | Type | Rôle |
| --- | --- | --- |
| `component` | string | composant canonique, ici `yiacad` |
| `surface` | string | surface d’émission: `kicad-pcb`, `kicad-sch`, `freecad-workbench`, `tui`, etc. |
| `action` | string | identifiant stable d’action, ex. `review.erc_drc` |
| `execution_mode` | string | `interactive`, `batch` ou `background` |
| `status` | string | `done`, `degraded`, `blocked` |
| `severity` | string | `info`, `warning`, `error` |
| `summary` | string | résumé lisible immédiatement |
| `artifacts` | array | liste de preuves et exports |
| `next_steps` | array | prochaines actions explicites |
## Champs optionnels
| Champ | Type | Rôle |
| --- | --- | --- |
| `details` | string/null | détail long-form ou message enrichi |
| `context_ref` | string/null | référence projet/runtime/workflow |
| `generated_at` | string | horodatage ISO |
| `provider` | string/null | provider IA ou backend, si applicable |
| `model` | string/null | modèle IA, si applicable |
| `latency_ms` | integer/null | latence utile à l’UI |
| `artifacts[].label` | string/null | libellé lisible |
| `artifacts[].kind` | string | `report`, `log`, `export`, `evidence` |
## Règles de compat
- `status` ne sort jamais de `done | degraded | blocked`
- `severity` ne sort jamais de `info | warning | error`
- les extensions doivent etre additives et optionnelles
- l’absence d’IA ne doit pas casser le contrat
- `artifacts` et `next_steps` doivent toujours etre structurés, jamais cachés dans `summary`
## Flux d’usage
```mermaid
flowchart LR
A["Action YiACAD"] --> B["Runner / backend"]
B --> C["Normalized output contract"]
C --> D["Command palette"]
C --> E["Review center"]
C --> F["Inspector"]
C --> G["TUI / logs / artifacts"]
```
## Exemple de lecture UI
- `status=degraded`
- `severity=warning`
- `summary=ERC/DRC completed with 3 warnings`
- `artifacts[0].path=/abs/path/to/erc-report.md`
- `next_steps[0]=open review center`
Cela permet a l’UI d’afficher directement une carte resultat sans logique ad hoc dependante de la surface source.
docs/handoffs/handoff_design.md
+13
View File
@@ -1,19 +1,32 @@
# Handoff — Design / UX
## Direction
- Surface: `YiACAD` / `Kill_LIFE`
- Lot: `T-UX-*`
- Références:
- `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_FEATURE_MAP_2026-03-20.md`
- `docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`
## Parcours
- Navigation:
- Command palette:
- Review center:
- Inspector:
## États
- Nominal :
- Erreurs :
- Loading :
- Provenance IA :
## Mapping inputs
- Boutons :
- Gestes :
- Raccourcis clavier :
## Assets & naming
- Icônes :
- Fonts :
- Couleurs :
- Toolbar / sidebar / inspector :
docs/index 2.md
+149
View File
@@ -0,0 +1,149 @@
# Kill_LIFE — Documentation opérateur
## Démarrage
- Installation : `docs/INSTALL.md`
- Runbook opérateur : `docs/RUNBOOK.md`
- FAQ : `docs/FAQ.md`
- Runtime home : `docs/RUNTIME_HOME.md`
- Pont compagnon : `docs/MASCARADE_BRIDGE.md`
- Architecture de référence : `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- Référence des séquences : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`, `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- Manifeste refonte : `docs/REFACTOR_MANIFEST_2026-03-20.md`
- Web research OSS : `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
- Stratégie CAD IA-native : `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`
- Lot YiACAD : `tools/cad/yiacad_fusion_lot.sh`
- Surfaces GUI YiACAD : `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`
- Hooks natifs YiACAD : `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`
- Audit UI/UX Apple-native : `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- Points d’insertion natifs : `docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`
- Index operateur YiACAD : `bash tools/cockpit/yiacad_operator_index.sh --action status`
- TUI UI/UX : `tools/cockpit/yiacad_uiux_tui.sh`
## Workflows opérationnels
- `docs/workflows/README.md`
- Templates d’issues : `.github/ISSUE_TEMPLATE/`
- Dispatch GitHub : `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- Validation locale : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
## Plans
- `docs/plans/README.md`
- `docs/plans/12_plan_gestion_des_agents.md`
- `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
- `docs/plans/REPO_DEEP_ANALYSIS_2026-03-11.md`
- `docs/plans/18_todo_enchainement_autonome_des_lots_utiles.md`
- `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`
- `docs/plans/20_todo_refonte_ui_ux_yiacad_apple_native.md`
## Gestion agents / IA
- Gestion des agents : `docs/plans/12_plan_gestion_des_agents.md`
- Orchestration IA : `docs/AI_WORKFLOWS.md`
- Paysage agentique : `docs/AGENTIC_LANDSCAPE.md`
- Matrice agentique spec/module : `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
## Evidence et rituels
- Evidence pack : `docs/evidence/evidence_pack.md`
- Rituels : `docs/rituals/`
- Handoffs : `docs/handoffs/`
- Templates : `docs/templates/`
## Références mémoire
- [Synthèse globale](../SYNTHESE_AGENTIQUE.md)
- [Rapport détaillé](assets/rapport/rapport_agentique.md)
- [Diagramme agentique](assets/rapport/diagramme_agentique.md)
- [Correspondance agents/systèmes](assets/rapport/synthese_correspondance_agents_systemes.md)
## Tests et preuve
- [Tests firmware](../firmware/test/)
- [Validation compliance](../compliance/evidence/)
- [Tests MCP](../test/)
## Infrastructure humaine & accès
- Machines SSH opérateur et rôles:
| Machine | Utilisateur | Priorité | Rôle | Port SSH | Port(s) service cible |
|---|---|---:|---|---:|---|
| `clems@192.168.0.120` | `clems` | `1` | Machine de pilotage / orchestration locale | `22` | `22` |
| `kxkm@kxkm-ai` | `kxkm` | `2` | Mac opérateur | `22` | `22` |
| `cils@100.126.225.111` | `cils` | `3` | Mac opérateur secondaire (`photon`, locké: seulement `Kill_LIFE`) | `22` | `22` |
| `root@192.168.0.119` | `root` | `4` | Serveur système / exécution matérielle | `22` | `22` |
- Politique de charge P2P: `Tower -> KXKM -> CILS -> local -> root`.
- `CILS` n’accueille pas de services essentiels ; uniquement le snapshot critique `Kill_LIFE` est autorisé.
- `root` reste la réserve opérationnelle quand `tower`, `kxkm`, `cils`, et le local sont saturés.
### Politique de load balancing (P2P)
```mermaid
flowchart LR
A[Tower: clems] --> B[KXKM: kxkm-ai]
B --> C[CILS: cils (photon-safe)]
C --> D[local]
D --> E[root (réserve)]
```
### Health-check SSH (script unique)
Exécute le script dédié:
```bash
bash tools/cockpit/ssh_healthcheck.sh
```
Le script écrit un log horodaté dans `artifacts/cockpit/` et sort en erreur si une machine est injoignable.
- `--json` : sortie JSON (utile pour cockpit / automation)
- `--no-log` : désactive la création de log
- `--verbose` : affiche plus de détails
Prérequis: droits SSH valides (clé/agent) déjà configurés et port 22 ouvert côté hôtes.
- Repos GitHub associés:
- `https://github.com/electron-rare/Kill_LIFE`
- `https://github.com/electron-rare/mascarade`
- `https://github.com/electron-rare/crazy-life` (orchestrateur privé référencé localement)
- Snapshot de synchro observé:
- [Etat machines/repos 2026-03-20](MACHINE_SYNC_STATUS_2026-03-20.md)
---
Index généré automatiquement.
## Delta mesh tri-repo 2026-03-20
- Contrat mesh: [docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md](docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md)
- Contrats publics: [specs/mesh_contracts.md](specs/mesh_contracts.md)
- Todo mesh: [docs/plans/19_todo_mesh_tri_repo.md](docs/plans/19_todo_mesh_tri_repo.md)
- Etat machines/sync: [docs/MACHINE_SYNC_STATUS_2026-03-20.md](docs/MACHINE_SYNC_STATUS_2026-03-20.md)
- TUI cockpit: [tools/cockpit/README.md](tools/cockpit/README.md)
## Full operator lane - 2026-03-20
- `docs/FULL_OPERATOR_LANE_2026-03-20.md`
- `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`
## Bundle global YiACAD 2026
- Audit global: [YIACAD_GLOBAL_REFACTOR_AUDIT_2026-03-20.md](YIACAD_GLOBAL_REFACTOR_AUDIT_2026-03-20.md)
- Evaluation IA: [YIACAD_GLOBAL_AI_INTEGRATION_ASSESSMENT_2026-03-20.md](YIACAD_GLOBAL_AI_INTEGRATION_ASSESSMENT_2026-03-20.md)
- Feature map: [YIACAD_GLOBAL_FEATURE_MAP_2026-03-20.md](YIACAD_GLOBAL_FEATURE_MAP_2026-03-20.md)
- Recherche OSS: [YIACAD_GLOBAL_OSS_RESEARCH_2026-03-20.md](YIACAD_GLOBAL_OSS_RESEARCH_2026-03-20.md)
- Architecture backend: [YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md](YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md)
- Spec: [../specs/yiacad_global_refonte_spec.md](../specs/yiacad_global_refonte_spec.md)
- Spec backend: [../specs/yiacad_backend_architecture_spec.md](../specs/yiacad_backend_architecture_spec.md)
- Plan: [plans/21_plan_refonte_globale_yiacad.md](plans/21_plan_refonte_globale_yiacad.md)
- TODO: [plans/21_todo_refonte_globale_yiacad.md](plans/21_todo_refonte_globale_yiacad.md)
- Index operateur: [YIACAD_OPERATOR_INDEX_2026-03-21.md](YIACAD_OPERATOR_INDEX_2026-03-21.md)
- TUI: `bash tools/cockpit/yiacad_refonte_tui.sh --action status|backend-architecture`
## 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.
docs/index.md
+112 -47
View File
@@ -1,66 +1,131 @@
# AI Agentic Embedded Base
# Kill_LIFE — Documentation opérateur canonique
Ce repo est un **socle** :
- **specs d’abord** (spec-driven)
- **standards injectés** (qualité & conformité)
- **agents + gates** (automation contrôlée)
- **exécution transparente** via outils (cockpit)
Cette page est l'entrée opérateur recommandée pour `Kill_LIFE`. Elle sert de table de routage entre le cockpit shell/TUI, les preuves, les runbooks et les documents de décision.
## Démarrer
## Entrées canoniques
- Installation : `docs/INSTALL.md`
- Runbook opérateur : `docs/RUNBOOK.md`
- FAQ : `docs/FAQ.md`
- Runtime home : `docs/RUNTIME_HOME.md`
- Pont vers le repo compagnon d’exécution : `docs/MASCARADE_BRIDGE.md`
- Carte fonctionnelle canonique : `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- Séquences opératoires : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`, `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
| Surface | Rôle | Entrée |
| --- | --- | --- |
| Produit / programme | vision, périmètre, arbitrages | `README.md` |
| Audit consolidé | forces, faiblesses, opportunités, risques, IA | `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md` |
| Cockpit opérateur | shell/TUI, contrats JSON, statut runtime | `bash tools/cockpit/yiacad_operator_index.sh --action status` |
| Gouvernance intelligence | owners, mémoire, prochaines actions | `bash tools/cockpit/intelligence_tui.sh --action status --json` |
| Gateway runtime/MCP/IA | synthèse consolidée des signaux runtime | `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json` |
| Refonte cockpit | raccourcis historiques et lots | `bash tools/cockpit/refonte_tui.sh --action status` |
| Lane opérateur | exécution consolidée, logs, preuves | `bash tools/cockpit/full_operator_lane.sh status --json` |
| Routine quotidienne | health-check, logs, mesh, synthèse | `bash tools/cockpit/run_alignment_daily.sh --json` |
| Chaîne spec-first | source de vérité documentaire | `specs/README.md` |
## Workflows professionnels (opérationnels)
## Navigation rapide
- `docs/workflows/README.md` (menu)
- Templates d’issues : `.github/ISSUE_TEMPLATE/`
- Dispatch distant et checks GitHub : `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- Validation locale et evidence locale : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
### Démarrage
## Plans (runbooks)
- Installation: `docs/INSTALL.md`
- Quickstart: `docs/QUICKSTART.md`
- Runbook opérateur: `docs/RUNBOOK.md`
- FAQ: `docs/FAQ.md`
- Runtime home: `docs/RUNTIME_HOME.md`
- Série complète : `docs/plans/README.md`
### Gouvernance et consolidation
## Labels
- Audit consolidé: `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md`
- Audit consolidé 2026-03-22: `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md`
- Manifeste refonte: `docs/REFACTOR_MANIFEST_2026-03-20.md`
- Contrat tri-repo: `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md`
- Gestion des agents: `docs/plans/12_plan_gestion_des_agents.md`
- Plan integration intelligence: `docs/plans/22_plan_integration_intelligence_agentique.md`
- TODO integration intelligence: `docs/plans/22_todo_integration_intelligence_agentique.md`
- Plan YiACAD Git EDA: `docs/plans/23_plan_yiacad_git_eda_platform.md`
- TODO YiACAD Git EDA: `docs/plans/23_todo_yiacad_git_eda_platform.md`
- Backlog canonique: `specs/04_tasks.md`
- Plan d'enchaînement autonome: `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
- Taxonomie : `docs/LABELS.md`
### Cockpit, preuves et santé runtime
## Evidence packs, templates et rituels
- Cockpit README: `tools/cockpit/README.md`
- Intelligence program TUI: `bash tools/cockpit/intelligence_tui.sh --action status`
- Memoire intelligence: `bash tools/cockpit/intelligence_tui.sh --action memory --json`
- Scorecard intelligence: `bash tools/cockpit/intelligence_tui.sh --action scorecard --json`
- Comparaison inter-repos: `bash tools/cockpit/intelligence_tui.sh --action comparison --json`
- File recommandations IA: `bash tools/cockpit/intelligence_tui.sh --action recommendations --json`
- Gateway runtime/MCP/IA: `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json`
- Index opérateur YiACAD: `bash tools/cockpit/yiacad_operator_index.sh --action status`
- Santé mesh: `bash tools/cockpit/mesh_health_check.sh --json`
- Santé SSH: `bash tools/cockpit/ssh_healthcheck.sh --json`
- Santé Mascarade/Ollama: `bash tools/cockpit/mascarade_runtime_health.sh --json`
- Surface de preuves: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`
- Surface de logs: `bash tools/cockpit/yiacad_logs_tui.sh --action status`
- Evidence pack : `docs/evidence/evidence_pack.md`
- Templates : `docs/templates/`
- Handoffs : `docs/handoffs/`
- Rituels : `docs/rituals/`
### Specs, plans et tâches
# Index documentation agentique
- Chaîne canonique: `specs/README.md`
- Intake: `specs/00_intake.md`
- Spec: `specs/01_spec.md`
- Architecture: `specs/02_arch.md`
- Plan: `specs/03_plan.md`
- Tâches: `specs/04_tasks.md`
Ce fichier centralise les liens vers les synthèses, rapports, diagrammes et evidence packs.
### Veille et benchmark
- [Synthèse globale](../SYNTHESE_AGENTIQUE.md)
- [Rapport détaillé](assets/rapport/rapport_agentique.md)
- [Diagramme agentique](assets/rapport/diagramme_agentique.md)
- [Synthèse correspondance agents/systèmes](assets/rapport/synthese_correspondance_agents_systemes.md)
- Veille OSS principale: `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
- Veille OSS / agentic / MCP 2026-03-22: `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-22.md`
- Veille CAD IA-native: `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`
- Workflows IA: `docs/AI_WORKFLOWS.md`
- Paysage agentique: `docs/AGENTIC_LANDSCAPE.md`
- Plateforme web Git EDA: `docs/YIACAD_GIT_EDA_PLATFORM_2026-03-22.md`
- Phase active 2026-03-22: alignement lot 22 + plan 23, durcissement cockpit/logs, veille officielle MCP/agentique/IA, priorisation Git/CI/artifacts/collab pour `web/`.
## Evidence packs
- [Evidence packs hardware](../hardware/blocks/README.md)
- [Evidence packs compliance](../compliance/evidence/)
- [Evidence packs firmware](../firmware/test/)
## Routines recommandées
## Tests et validation
- [Tests firmware](../firmware/test/)
- [Tests hardware](../hardware/blocks/)
- [Validation compliance](../compliance/evidence/)
### Routine quotidienne
## Conventions et synchronisation
- [Conventions multi-agent](../standards/global/coding.md)
- [Synchronisation et traçabilité](../docs/AI_WORKFLOWS.md)
```bash
bash tools/cockpit/run_alignment_daily.sh --json
bash tools/cockpit/log_ops.sh --action summary --json
bash tools/cockpit/mesh_health_check.sh --json --load-profile tower-first
```
---
### Revue de lots
> Index généré automatiquement (GPT-4.1)
```bash
bash tools/run_autonomous_next_lots.sh status
bash tools/cockpit/refonte_tui.sh --action lots-status
bash tools/cockpit/refonte_tui.sh --action weekly-summary
```
### Gouvernance intelligence
```bash
bash tools/cockpit/lot_chain.sh status
bash tools/cockpit/intelligence_tui.sh --action next-actions
bash tools/cockpit/intelligence_tui.sh --action memory --json
bash tools/cockpit/intelligence_tui.sh --action scorecard --json
bash tools/cockpit/intelligence_tui.sh --action comparison --json
bash tools/cockpit/intelligence_tui.sh --action recommendations --json
bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json
```
### Validation locale stable
```bash
bash tools/test_python.sh --suite stable
python3 tools/validate_specs.py --strict --require-mirror-sync
```
## Pilotage des extensions VS Code
Les extensions ne vivent pas dans ce repo, mais `Kill_LIFE` reste leur source de vérité documentaire et opératoire:
- `kill-life-studio`: produit, specs, décisions, critères d'acceptation
- `kill-life-mesh`: orchestration multi-repo, contrats, dépendances, ownership
- `kill-life-operator`: runbooks, checks, preuves, exécution
Le socle commun validé côté extensions est documenté dans `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md`.
## Références mémoire et preuves
- Synthèse globale: `SYNTHESE_AGENTIQUE.md`
- Evidence pack: `docs/evidence/evidence_pack.md`
- Handoffs: `docs/handoffs/`
- Templates: `docs/templates/`
- Tests: `test/`
docs/plans/12_plan_gestion_des_agents.md
+672 -36
View File
@@ -1,48 +1,684 @@
# 12) Plan de gestion des agents
## Objectif
Définir rôles, prompts, rituels, gates, handoffs et evidence pack pour garder un système agentique stable.
Last updated: 2026-03-22
Ce document pilote la gouvernance agentique et les 3 plans opérationnels: **PM**, **Architect-Firmware** et **SyncOps**.
Matrice explicite specs/modules -> agents dédiés: `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
## Consolidation 2026-03-21 - extensions d'abord
La passe active retient `kill-life-studio` comme produit pilote. `kill-life-mesh` et `kill-life-operator` n'ouvrent pas de spécialisation profonde tant que le socle `projet actif + grounding + tests` n'est pas validé dans Studio.
| Lead | Sous-agents | Compétences | Backlog initial |
| --- | --- | --- | --- |
| `PM-Mesh` | `Plan-Orchestrator`, `Risk-Triager`, `Release-Gate` | arbitrage, backlog, release gate | baseline sale, P0/P1, critères de "prêt avant public" |
| `Docs-Research` | `Doc-Entry`, `Mermaid-Map`, `Feature-Map`, `Runbook-Editor` | consolidation doc, benchmark, cartes | `README`, `docs/index`, `tools/cockpit/README`, `specs/README`, audit unique |
| `Studio-Product` | `UX-Lead`, `Context-Builder`, `Artifact-Model`, `Extension-Test` | UX auteur, contexte chat, artefacts, tests | projet actif, workflow `brief -> spec -> decisions -> AC -> plan`, tests unitaires et extension-host |
| `Mesh-Contracts` | `Handoff-Guard`, `Contract-View`, `Dependency-Mapper` | contrats, handoffs, ownership | reprendre le socle Studio validé puis spécialiser les vues multi-repo |
| `Operator-Lane` | `Runbook-Guard`, `Evidence-Runner`, `Log-Ops` | runbooks, preuves, exécution | reprendre le socle Studio validé puis spécialiser checks et evidence |
| `Runtime-Companion` | `MCP-Health`, `Prompt-Eval`, `Bridge-Queue` | santé runtime/MCP, dégradation maîtrisée, prompt eval | gateway canonique `ready/degraded/blocked` via `runtime_ai_gateway.sh` |
| `QA-Compliance` | `Contract-Tests`, `Shell-Harness`, `Smoke-E2E` | tests shell/TUI, contrats JSON, smoke VSIX | stable suite Python, tests cockpit ciblés, `runtime_ai_gateway.sh`, smoke multi-root |
| `OSS-Watch` | `VSCode-Agent-Benchmark`, `Agent-Framework-Benchmark`, `MCP-Benchmark` | veille web et décisions d'adoption | benchmark unique Roo Code / OpenHands / LangGraph / MCP |
## Delta 2026-03-21 - lane intelligence program
- Le lot dedie `22` ouvre une surface cockpit propre:
- `tools/cockpit/intelligence_tui.sh`
- `docs/plans/22_plan_integration_intelligence_agentique.md`
- `docs/plans/22_todo_integration_intelligence_agentique.md`
- La passerelle courte au-dessus de cette lane est:
- `tools/cockpit/runtime_ai_gateway.sh`
- Cette surface publie aussi une memoire exploitable:
- `artifacts/cockpit/intelligence_program/latest.json`
- `artifacts/cockpit/intelligence_program/latest.md`
- Owner principal de la surface:
- `QA-Compliance / Shell-Harness / Contract-Tests` pour la TUI, les logs et le contrat JSON
- Owner principal de la continuite documentaire:
- `Docs-Research / Doc-Entry / Mermaid-Map` pour la spec, la feature map et la veille 2026
- Routine recommandee pour `PM-Mesh`, `Docs-Research` et `QA-Compliance`:
- `bash tools/cockpit/lot_chain.sh status`
- `bash tools/cockpit/intelligence_tui.sh --action status --json`
- `bash tools/cockpit/intelligence_tui.sh --action next-actions`
- `bash tools/cockpit/intelligence_tui.sh --action memory --json`
- `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json`
## Delta 2026-03-22 - lane web Git EDA + intelligence
- Le lot intelligence couvre maintenant explicitement le backlog `web/` et le `plan 23`.
- Le binome d'audit lecture seule utilise dans cette passe:
- `Hilbert` -> audit contrats/spec/plan/TUI intelligence
- `Huygens` -> audit `web/` Git EDA, GraphQL, realtime, queue et workers
- Owners canoniques de la slice `web/`:
- `Web-CAD-Platform` -> `Project-Service`, `Product-Web`, `Review-Assist`
- `Realtime-Collab` -> `Yjs-Bridge`, `Presence-Transport`
- `EDA-CI-Orchestrator` -> `Worker-Runner`, `Artifacts-Bridge`
- Skills a privilegier sur cette lane:
- `bash-cli-tui` pour les TUIs et contrats shell
- `playwright` pour les checks UI reels quand requis
- `openai-docs` pour les integrations officielles OpenAI quand la lane review-assist s'ouvre
- Routine recommandee pour cette lane:
- `bash tools/cockpit/intelligence_tui.sh --action status --json`
- `bash tools/cockpit/intelligence_tui.sh --action next-actions`
- `bash tools/cockpit/yiacad_operator_index.sh --action status`
- `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json`
## Carte opérationnelle des 3 plans
| Plan | Lead | Sous-agents actifs | Compétences | Mission de lot | Prochaine action |
| --- | --- | --- | --- | --- | --- |
| PM | `PM-Mesh` | `PM-Plan`, `PM-Choix`, `PM-Doc` | Orchestration lot, preuve JSON, arbitrage P0-P2 | piloter `run_autonomous_next_lots` | Lancer `yiacad-fusion` dès stabilisation du prérequis runtime |
| Architect-Firmware | `Arch-Mesh` | `Runtime-Companion`, `Schema-Guard`, `Embedded-CAD`, `Firmware` | robustesse ready/degraded/blocked, host-first CAD, intégrations IA-native | sécuriser lanes MCP/CAD + préflight mesh | finaliser `yiacad-fusion` (prepare→smoke→status) |
| SyncOps | `SyncOps` | `SSH-Health`, `Log-Ops`, `Doc-Runbook` | SSH, TUI, logs, incidents | piloter load-balancing P2P et registre d’incidents | clôturer le backlog `mesh` + purge TTL quotidienne contrôlée |
| DesignOps-UI | `UX-Lead` | `Apple-HIG`, `CAD-UX`, `UI-Research`, `TUI-Ops` | Apple HIG, UI architecture macOS, surfaces KiCad/FreeCAD, TUI opératoire | piloter la refonte UI/UX YiACAD Apple-native | passer du plugin/workbench Python au shell natif compilé et aux commandes IA contextualisées |
```mermaid
flowchart LR
PM[Plan PM] -->|ordonne| lots[run_autonomous_next_lots.sh]
lots -->|preuves| arch[Architect-Firmware]
lots -->|observabilité| ops[SyncOps]
arch -->|contracts| docs[(docs/*)]
ops -->|incidents + logs| docs
docs -->|feedback| lots
```
## Labels recommandés
- `type:agentics` + `ai:plan`
## Étapes
- `type:agentics`
- `ai:plan`
- `ai:hold`
- `priority:p0/p1/p2`
### 1. Rôles
- [ ] PM
- [ ] Architect
- [ ] Firmware
- [ ] Hardware
- [ ] QA
- [ ] Doc
## Référentiel multi-plans
### 2. Prompts standard
Chaque prompt doit définir :
- Entrées (sanitisées)
- Sorties attendues (artefacts)
- Contraintes (scope, denylist)
- Format de rapport
| Plan | Responsable | Sous-agents | Compétences | Missions clés |
| --- | --- | --- | --- | --- |
| PM | `PM-Mesh`, `PM-Plan`, `PM-Choix` | coordination lot, priorité, arbitrage, preuves | `specs/04_tasks.md`, `docs/plans/18_plan_enchainement_*`, `docs/plans/19_todo_mesh_tri_repo.md` | cycle lot, dépendances, revue produit |
| Architect-Firmware | `Arch-Mesh`, `Runtime-Companion`, `Embedded-CAD`, `Firmware` | architecture, contracts, runtime, robustesse | `docs/AGENTIC_LANDSCAPE.md`, `docs/REFACTOR_MANIFEST_2026-03-20.md`, `tools/autonomous_next_lots.py`, `tools/hw/*`, `tools/cockpit/mesh_sync_preflight.sh` | robustesse `ready/degraded/blocked`, host-first CAD |
| SyncOps | `SyncOps`, `SSH-Health`, `Log-Ops` | SSH, observabilité, logs, purge | `tools/cockpit/ssh_healthcheck.sh`, `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/log_ops.sh`, `tools/cockpit/mesh_sync_preflight.sh`, `tools/cockpit/mesh_health_check.sh`, `docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md` | alignment 4 cibles + incidents réseau/runtime |
### 3. Handoffs
- [ ] Handoff Firmware
- [ ] Handoff Hardware
- [ ] Handoff Design
- [ ] Handoff Creative
## Plan 1 — PM (pilotage + lot)
### 4. Gates
- [ ] Label enforcement
- [ ] Scope guard
- [ ] Build/test
- [ ] Compliance (si applicable)
### Objectifs
### 5. Evidence pack
- [ ] Logs CI
- [ ] Diffs
- [ ] Décisions (ADR)
- Détecter les lots utiles (`run_autonomous_next_lots`), exécuter en cycle standard et tenir la preuve.
- Valider la matrice **lot → owner → dépendances → rollback**.
- Gérer les priorités P0/P1/P2 et la revue quotidienne.
## Critère de sortie
✅ Les agents sont utiles, prédictibles, et “safe by default”.
### I/O attendues
## Références
- `docs/handoffs/*`
- `docs/rituals/*`
- `bash tools/run_autonomous_next_lots.sh status`
- `bash tools/run_autonomous_next_lots.sh run`
- `bash tools/run_autonomous_next_lots.sh json`
- `tools/autonomous_next_lots.py` doit produire `18_plan_enchainement_autonome_des_lots_utiles.md` et `18_todo_enchainement_autonome_des_lots_utiles.md`.
### Priorités
- P0: stabiliser `post-e2e-hardening`, restaurer `clems` dans le preflight, puis reprendre `zeroclaw-integrations`.
- P1: corriger les lots `mcp-runtime` et `cad-mcp-host`.
- P2: finaliser `python-local` après stabilité runtime.
## Plan 2 — Architect / Firmware
### Objectifs
- Finaliser intégration runtime IA-native et lanes de robustesse.
- Stabiliser scripts MCP/CAD en mode `host-first` avec fallback maîtrisé.
- Assurer cohérence des contrats dans `docs/*` et `specs/*`.
### I/O attendues
- `bash tools/ai/zeroclaw_integrations_lot.sh verify --json`
- `bash tools/ai/zeroclaw_integrations_up.sh --json`
- `bash tools/ai/zeroclaw_integrations_status.sh --json`
- `bash tools/ai/zeroclaw_integrations_import_n8n.sh --json`
- `bash tools/hw/cad_stack.sh doctor`
- `bash tools/hw/run_kicad_mcp.sh --doctor`
### Priorités
- P0: consolider le bridge `Full operator lane` en mode container-safe et degraded-safe.
- P1: finaliser `mcp-runtime` et `cad-mcp-host`.
- P2: verrouiller la stratégie Python repo-locale.
## Plan 3 — SyncOps
### Objectifs
- Assurer la convergence des 4 cibles SSH.
- Appliquer la politique de charge P2P (`tower-first` / `photon-safe`) sur les préchecks mesh pour éviter de forcer les services sur `cils`.
- Centraliser health-check, logs (analyse + purge), préflight mesh, et registre d'incidents.
- Alimenter la mémoire d'exécution avec preuves JSON.
### I/O attendues
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/mascarade_runtime_health.sh --json`
- `bash tools/cockpit/run_alignment_daily.sh --json [--skip-healthcheck]`
- `bash tools/cockpit/mesh_sync_preflight.sh --json`
- `bash tools/cockpit/log_ops.sh --action summary|list|purge --json`
- `bash tools/cockpit/mesh_health_check.sh --json --load-profile [tower-first|photon-safe]`
- `bash tools/cockpit/refonte_tui.sh --action mesh-preflight`
### Priorités
- P0: confirmer l'opérateur daily sur 4 cibles et restaurer la visibilité preflight de `clems`.
- P0: maintenir `cils` hors charges essentielles (`Kill_LIFE` prioritaire, pas de service durable sur photon).
- P1: tenir la matrice `logs` (summary/list/purge) + TTL.
- P2: documenter les incidents réseau/runtime dans le registre.
- P0: vérifier la convergence du load-balancing P2P `Tower -> KXKM -> CILS -> local -> root` à chaque run.
## Registre d'incidents réseau/runtime
- Voir: `docs/MESH_SYNC_INCIDENT_REGISTER_2026-03-20.md`
- Format: horodatage / cible / couche / statut / preuve / ETA / propriétaire.
## Rôles actifs
1. `PM-Mesh` / `PM-Plan`
2. `Arch-Mesh` / `Schema-Guard`
3. `Embedded-CAD` / `CAD-Intégration`
4. `Runtime-Companion` / `Runtime-Smoke`
5. `SyncOps` / `Log-Ops`
6. `Doc-Runbook`
## Couverture explicite specs/modules
- Chaque specification et chaque module operatoire majeur ont maintenant un agent pilote, un sous-agent, un `write_set` et une sortie attendue.
- La matrice de reference est publiee dans `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`.
- Les skills locales a privilegier sur les surfaces outillees restent: `bash-cli-tui` pour les scripts shell/TUI, `playwright` pour les verifications UI reelles, `openai-docs` pour les integrations officielles OpenAI quand elles deviennent necessaires.
- Passe structurante en cours: `mesh_sync_preflight` consomme maintenant le registre machine/capacite comme source de verite runtime; prochaine extension cible `ssh_healthcheck`, `run_alignment_daily` et les derniers chemins repo candidats.
## Checkpoint (résumé)
- `T-MESH-001` : contrat mesh tri-repo versionné — aligné
- `T-MESH-002` : preflight `ready/degraded/blocked` — aligné
- `T-MESH-003` : ownership `owner_repo / owner_agent` — aligné
- `T-MESH-005` : propagation `mascarade` — en cours
- `T-MESH-006` : handshake `crazy_life` — en cours
- `T-RE-001` / `T-RE-105` : plans + compétences — en exécution
- `T-OL-001` : full operator lane valide sur `clems` — aligné
- `T-OL-002` : propagation + restauration preflight `clems` — en cours
- `T-OL-002` : propagation + restauration preflight `clems` — aligne
- `T-OL-003` : note de compatibilité provider/runtime — aligné
- `T-OL-004` : TUI de sync du patchset opérateur — aligné
### Lot CAD (inclus dans Architect-Firmware)
### Objectifs
- Intégrer YiACAD dans le lot Architect-Firmware sans altérer la charge sur `cils`/`photon`.
- Conserver les forks locales et distants de KiCad/FreeCAD en mode isolé `kill-life-ai-native`.
- Produire des artefacts de santé CAD auditables et une procédure de rollback claire, avec priorité à la stabilité de la couche runtime.
### I/O attendues
- `bash tools/cad/yiacad_fusion_lot.sh --action prepare`
- `bash tools/cad/yiacad_fusion_lot.sh --action smoke`
- `bash tools/cad/yiacad_fusion_lot.sh --action status`
- `bash tools/cad/yiacad_fusion_lot.sh --action logs`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:prepare`
- `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion:smoke`
### Priorités
- P0: garder `prepare` + `status` + `logs` + `clean-logs` stables, avec un blocage KiCad host explicite et traçable.
- P1: maintenir les preuves/logs à jour dans `specs/04_tasks.md` et `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`.
- P2: sécuriser la réconciliation des forks distants et le fallback container.
- `T-CAD-001` : lot YiACAD intégré — implémenté/documenté, lane runtime encore `blocked` côté KiCad host
## Affectation active des lots ouverts
| Tâche / lot | Agent pilote | Sous-agent | Compétences / skills | Write set principal |
| --- | --- | --- | --- | --- |
| `T-RE-204` / `zeroclaw-integrations` | `PM-Mesh` | `Runtime-Smoke` | triage lot, runtime local, `bash-cli-tui` | `specs/zeroclaw_dual_hw_todo.md`, `tools/cockpit/lot_chain.sh`, `tools/cockpit/run_next_lots_autonomously.sh` |
| `mesh-governance` | `PM-Mesh` | `Schema-Guard` | contrats mesh, handoff, preuve CI | `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md`, `docs/plans/19_todo_mesh_tri_repo.md`, `tools/cockpit/mesh_sync_preflight.sh` |
| `T-RE-215` / `mascarade-model-profiles` | `Runtime-Companion` | `Provider-Bridge` | routing provider/model, profils runtime, `bash-cli-tui` | `specs/contracts/mascarade_model_profiles.kxkm_ai.json`, `tools/cockpit/mascarade_models_tui.sh`, `tools/ops/operator_live_provider_smoke.py`, `tools/ops/sync_mascarade_agents_kxkm.sh` |
| `T-RE-218` / `mascarade-ollama-live` | `Runtime-Companion` | `Provider-Bridge` | bridge Ollama local, compat runtime, profils `ollama-first`, `bash-cli-tui` | `specs/contracts/mascarade_model_profiles.kxkm_ai.json`, `docs/MASCARADE_MODEL_PROFILES_KXKM_AI_2026-03-20.md`, `tools/ops/sync_mascarade_agents_kxkm.sh` |
| `T-RE-219` / `mascarade-agent-smoke` | `Runtime-Companion` | `Runtime-Smoke` | smoke API live, artefacts JSON, validation ciblee | `tools/ops/smoke_mascarade_agents_kxkm.sh`, `artifacts/ops/mascarade_agent_smoke/*`, `docs/MASCARADE_MODEL_PROFILES_KXKM_AI_2026-03-20.md` |
| `T-RE-221` / `mascarade-ui-presets` | `Runtime-Companion` | `UI-Dispatch` | presets UI, registre agents, publication front | `/home/kxkm/mascarade-main/web/src/pages/Agents.tsx`, `docs/MASCARADE_MODEL_PROFILES_KXKM_AI_2026-03-20.md` |
| `T-RE-222` / `mascarade-runtime-health` | `SyncOps` | `Runtime-Smoke` | health live, Ollama, JSON cockpit, runbook daily | `tools/cockpit/mascarade_runtime_health.sh`, `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/README.md` |
| `T-RE-223` / `oss-chat-presets-research` | `PM` | `Research-Curator` | veille web, chats multi-agents, personas, orchestration | `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`, `specs/04_tasks.md` |
| `T-RE-224` / `operator-runtime-health-surface` | `SyncOps` | `TUI-Ops` | TUI cockpit, lane operateur, contrat JSON, `bash-cli-tui` | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/README.md` |
| `T-RE-225` / `mascarade-logs-tui` | `SyncOps` | `Log-Curator` | logs runtime, purge contrôlée, TUI cockpit, `bash-cli-tui` | `tools/cockpit/mascarade_logs_tui.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/README.md` |
| `T-RE-226` / `operator-mascarade-logs-bridge` | `SyncOps` | `Lane-Guard` | lane operateur, logs runtime, hints API, `bash-cli-tui` | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/mascarade_logs_tui.sh`, `specs/04_tasks.md` |
| `T-RE-227` / `operator-native-logs-mode` | `SyncOps` | `Lane-Guard` | lane operateur, logs natifs, hints API, `bash-cli-tui` | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/README.md`, `specs/04_tasks.md` |
| `T-RE-228` / `operator-logs-tui-reroute` | `SyncOps` | `TUI-Ops` | TUI cockpit, lane operateur, contrat JSON, `bash-cli-tui` | `tools/cockpit/refonte_tui.sh`, `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/README.md` |
| `T-RE-229` / `operator-logs-shortcuts` | `SyncOps` | `TUI-Ops` | TUI cockpit, raccourcis logs, ergonomie operateur, `bash-cli-tui` | `tools/cockpit/refonte_tui.sh`, `tools/cockpit/README.md`, `specs/04_tasks.md` |
| `T-RE-230` / `operator-post-run-log-snapshot` | `SyncOps` | `Lane-Guard` | lane operateur, snapshot latest, artefacts runtime, `bash-cli-tui` | `tools/cockpit/full_operator_lane.sh`, `specs/04_tasks.md`, `tools/cockpit/README.md` |
| `T-RE-231` / `daily-mascarade-log-snapshot` | `SyncOps` | `Doc-Runbook` | routine daily, logs runtime, synthèse opératoire, `bash-cli-tui` | `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/README.md`, `specs/04_tasks.md` |
| `T-RE-232` / `mascarade-incident-brief` | `PM` | `Doc-Runbook` | markdown opératoire, incidents runtime, handoff quotidien | `tools/cockpit/render_mascarade_incident_brief.sh`, `tools/cockpit/run_alignment_daily.sh`, `specs/04_tasks.md` |
| `T-RE-233` / `mascarade-incident-registry` | `PM` | `Doc-Runbook` | registre incidents, historique horodaté, handoff agentique | `tools/cockpit/mascarade_incident_registry.sh`, `artifacts/cockpit/*`, `specs/04_tasks.md` |
| `T-RE-234` / `weekly-mascarade-ops-embed` | `SyncOps` | `Doc-Runbook` | synthèse hebdo, brief incident, registre, `bash-cli-tui` | `tools/cockpit/render_weekly_refonte_summary.sh`, `tools/cockpit/render_mascarade_incident_brief.sh`, `tools/cockpit/mascarade_incident_registry.sh` |
| `T-RE-235` / `mascarade-observability-research` | `PM` | `Research-Curator` | veille OSS, observabilité légère, incidents, status pages | `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`, `specs/04_tasks.md` |
| `T-RE-236` / `daily-operator-summary-mascarade` | `SyncOps` | `Doc-Runbook` | synthèse quotidienne, handoff opérateur, markdown/json | `tools/cockpit/render_daily_operator_summary.sh`, `tools/cockpit/run_alignment_daily.sh`, `specs/04_tasks.md` |
| `T-RE-237` / `mascarade-ops-feature-map` | `PM` | `Doc-Runbook` | feature map Mermaid, cartographie agents, roadmap ops | `docs/MASCARADE_OPS_OBSERVABILITY_FEATURE_MAP_2026-03-21.md`, `specs/04_tasks.md` |
| `T-RE-238` / `operator-daily-summary-bridge` | `SyncOps` | `Lane-Guard` | lane operateur, synthèse quotidienne, contrat JSON | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/render_daily_operator_summary.sh`, `specs/04_tasks.md` |
| `T-RE-239` / `incident-registry-severity-map` | `PM` | `Doc-Runbook` | priorisation incidents, gravité, handoff opérateur | `tools/cockpit/mascarade_incident_registry.sh`, `specs/04_tasks.md` |
| `T-RE-240` / `weekly-severity-rollup` | `SyncOps` | `Doc-Runbook` | synthèse hebdo, priorité incidents, handoff opérateur | `tools/cockpit/render_weekly_refonte_summary.sh`, `tools/cockpit/mascarade_incident_registry.sh`, `specs/04_tasks.md` |
| `T-RE-241` / `incidents-tui-surface` | `SyncOps` | `TUI-Ops` | TUI cockpit, incident review, runbook daily | `tools/cockpit/mascarade_incidents_tui.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/README.md` |
| `T-RE-242` / `incident-queue-export` | `SyncOps` | `Doc-Runbook` | file d’incidents, tri priorité/sévérité, handoff quotidien | `tools/cockpit/render_mascarade_incident_queue.sh`, `tools/cockpit/run_alignment_daily.sh`, `specs/04_tasks.md` |
| `T-RE-243` / `daily-final-status-reconcile` | `SyncOps` | `Lane-Guard` | statut final daily, contrat JSON, cohérence runbook | `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/render_daily_operator_summary.sh`, `tools/cockpit/README.md` |
| `T-RE-244` / `incident-queue-tui-surface` | `SyncOps` | `TUI-Ops` | TUI cockpit, queue priorisée, ergonomie opérateur | `tools/cockpit/mascarade_incidents_tui.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/README.md` |
| `T-RE-245` / `incident-queue-summary-embed` | `SyncOps` | `Doc-Runbook` | synthèses Markdown, queue priorisée, handoff opérateur | `tools/cockpit/render_daily_operator_summary.sh`, `tools/cockpit/render_weekly_refonte_summary.sh`, `specs/04_tasks.md` |
| `T-RE-246` / `incident-queue-native-lane-bridge` | `SyncOps` | `Lane-Guard` | lane opérateur, queue priorisée, contrat JSON cockpit | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/render_mascarade_incident_queue.sh`, `specs/04_tasks.md` |
| `T-RE-247` / `daily-priority-rollup` | `SyncOps` | `Doc-Runbook` | handoff quotidien, résumé priorité/sévérité, Markdown opérateur | `tools/cockpit/render_daily_operator_summary.sh`, `tools/cockpit/README.md`, `specs/04_tasks.md` |
| `T-RE-248` / `incident-watch-tui` | `SyncOps` | `TUI-Ops` | watchboard terminal, garde opérateur, lecture ultra-courte | `tools/cockpit/mascarade_incidents_tui.sh`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/README.md` |
| `T-RE-249` / `native-lane-incident-rollup` | `SyncOps` | `Lane-Guard` | JSON opérateur, priorité/sévérité, automation-friendly | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/render_daily_operator_summary.sh`, `specs/04_tasks.md` |
| `T-RE-250` / `daily-incident-watch-artifact` | `SyncOps` | `Doc-Runbook` | artefact court de garde, JSON/Markdown, runbook quotidien | `tools/cockpit/render_mascarade_incident_watch.sh`, `tools/cockpit/run_alignment_daily.sh`, `specs/04_tasks.md` |
| `T-RE-251` / `watchboard-research` | `PM` | `Research-Curator` | veille officielle, watchboard/status pages, arbitrage léger vs lourd | `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`, `specs/04_tasks.md` |
| `T-RE-252` / `native-lane-watch-bridge` | `SyncOps` | `Lane-Guard` | watchboard court, lane opérateur, contrat JSON | `tools/cockpit/full_operator_lane.sh`, `tools/cockpit/render_mascarade_incident_watch.sh`, `specs/04_tasks.md` |
| `T-RE-253` / `weekly-watch-embed` | `SyncOps` | `Doc-Runbook` | synthèse hebdo, watchboard court, handoff opérateur | `tools/cockpit/render_weekly_refonte_summary.sh`, `tools/cockpit/render_mascarade_incident_watch.sh`, `specs/04_tasks.md` |
| `T-RE-254` / `operator-index-watch-shortcuts` | `SyncOps` | `TUI-Ops` | index opérateur, raccourcis garde, ergonomie courte | `tools/cockpit/yiacad_operator_index.sh`, `tools/cockpit/README.md`, `specs/04_tasks.md` |
| `T-RE-255` / `watch-history-registry` | `SyncOps` | `Doc-Runbook` | historique watchboard, suivi P1/P2/P3, mémoire opératoire | `tools/cockpit/render_mascarade_watch_history.sh`, `artifacts/cockpit/*`, `specs/04_tasks.md` |
| `T-RE-256` / `daily-watch-history-bridge` | `SyncOps` | `Lane-Guard` | routine daily, historique watchboard, contrat JSON | `tools/cockpit/run_alignment_daily.sh`, `tools/cockpit/render_mascarade_watch_history.sh`, `specs/04_tasks.md` |
| `T-RE-257` / `weekly-watch-history-embed` | `SyncOps` | `Doc-Runbook` | synthèse hebdo, historique de tendance, handoff opérateur | `tools/cockpit/render_weekly_refonte_summary.sh`, `tools/cockpit/render_mascarade_watch_history.sh`, `specs/04_tasks.md` |
| `T-RE-209` / `yiacad-fusion` | `Arch-Mesh` | `CAD-Bridge` | host-first CAD, fork strategy, `bash-cli-tui`, OSS benchmark | `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`, `tools/cad/yiacad_fusion_lot.sh`, `tools/cad/ai_native_forks.sh` |
| `T-RE-210` / `yiacad-fusion` | `Arch-Mesh` | `CAD-Smoke` | smoke KiCad/FreeCAD/OpenSCAD, status snapshot, rollback | `tools/autonomous_next_lots.py`, `tools/cockpit/refonte_tui.sh`, `tools/cockpit/render_weekly_refonte_summary.sh` |
| `T-UX-001` / audit-uiux-apple` | `UX-Lead` | `UI-Research` | Apple HIG, information architecture, audit produit | `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`, `docs/YIACAD_APPLE_UI_UX_OSS_RESEARCH_2026-03-20.md` |
| `T-UX-002` / shell-ui-native` | `UX-Lead` | `CAD-UX` | KiCad/FreeCAD surface design, command palette, sidebar/inspector | `specs/yiacad_uiux_apple_native_spec.md`, `.runtime-home/cad-ai-native-forks/kicad-ki/*`, `.runtime-home/cad-ai-native-forks/freecad-ki/*` |
| `T-UX-003` / uiux-tui` | `SyncOps` | `TUI-Ops` | `bash-cli-tui`, logs, purge contrôlée | `tools/cockpit/yiacad_uiux_tui.sh`, `artifacts/uiux_tui/*` |
| `T-RE-214` / machine-registry-runtime` | `SyncOps` | `Schema-Guard` | registre machine, preflight mesh, `bash-cli-tui` | `specs/contracts/machine_registry.mesh.json`, `tools/cockpit/machine_registry.sh`, `tools/cockpit/mesh_sync_preflight.sh` |
| `T-RE-301` | `SyncOps` | `Doc-Runbook` | synthèse opératoire, logs, `bash-cli-tui` | `tools/cockpit/render_weekly_refonte_summary.sh`, `artifacts/cockpit/weekly_refonte_summary.md` |
Delta lot 2026-03-20:
- le runbook cockpit integre maintenant un health-check `Mascarade/Ollama` avant le preflight mesh, avec sortie JSON et artefacts dedies
- la veille OSS couvre explicitement les patterns `chat multi-agents + presets/personas` reutilisables pour Mascarade et Kill_LIFE
- la surface `full_operator_lane` reste maintenant exploitable meme si l'API locale `localhost:3100` est indisponible, avec JSON contractuel et sortie non silencieuse
- le daily cockpit integre maintenant une file d'incidents Mascarade priorisee et recalcule son statut final apres la synthese operateur quotidienne
- la queue d'incidents est maintenant visible dans la TUI cockpit et dans les syntheses Markdown daily/weekly
- la lane operateur native remonte maintenant aussi la queue d'incidents, et le daily affiche un rollup court P1/P2/P3 pour la lecture de garde
- la TUI cockpit expose maintenant un `incident-watch` court, et la lane native publie aussi ce rollup au niveau top-level JSON
- le daily cockpit publie maintenant aussi un artefact `incident-watch` dedie, tandis que la veille officielle `OpenStatus` / `OneUptime` reste documentee comme benchmark futur
- la lane native embarque maintenant aussi ce watchboard court, et la synthese hebdomadaire l'affiche a son tour pour une revue plus rapide
- l'index operateur YiACAD expose maintenant `incident-watch` et `incident-history`, et un historique watch dedie suit l'evolution des priorites sur plusieurs runs
- la routine daily publie maintenant aussi l'historique `watch`, et la synthese hebdomadaire l'affiche pour suivre la tendance des priorites
| `T-RE-302` | `Docs-Research` | `Mermaid-Map` | documentation, owner mapping, Mermaid | `docs/plans/12_plan_gestion_des_agents.md`, `docs/plans/19_todo_mesh_tri_repo.md` |
| `T-RE-303` | `Docs-Research` | `Evidence-Pack` | synthèse, sources de vérité, mémoire d’exécution | `SYNTHESE_AGENTIQUE.md` |
| `T-RE-304` | `SyncOps` | `Log-Ops` | checklist lot, preflight, preuve logs | `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`, `artifacts/cockpit/weekly_refonte_summary.md` |
| `T-OL-002` | `SyncOps` | `Lane-Repair` | propagation conservative, SSH, `bash-cli-tui` | `tools/cockpit/full_operator_lane_sync.sh`, `docs/MACHINE_SYNC_STATUS_2026-03-20.md` |
| `T-OL-003` | `Docs-Research` | `Compat-Guard` | veille officielle, compat provider/runtime | `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`, `docs/FULL_OPERATOR_LANE_2026-03-20.md` |
## Delta 2026-03-20 13:00
- `T-CI-001` : workflow CI visible pour `agent_handoff`, `repo_snapshot`, `workflow_handshake` — aligné
- `T-LOT-001` : consommation du checker mesh dans `autonomous_next_lots` — lot `mesh-governance` ciblé
- `Runtime-Smoke` et `Schema-Consumer` consomment désormais les contrats depuis la lane soeur `Kill_LIFE-main`
- `docs/plans/19_todo_mesh_tri_repo.md` devient la checklist lot-level de référence pour la passe mesh courante
## Delta 2026-03-20 14:20 - full operator lane
- `Docs-Research`: published the operator-lane contract, Mermaid and README deltas.
- `Runtime-Companion`: kept the mascarade live bridge explicit and degraded-safe.
- `Web-Cockpit`: connected the new live-provider local action to the existing Crazy Lane routes.
- `SyncOps`: added the dedicated TUI runbook and staged the lot on the mesh lanes.
## Delta 2026-03-20 14:45 - post-E2E hardening
- `Runtime-Companion`: moved the live bridge to a container-safe Node runner while keeping Python parity for host-side debugging.
- `Compat-Guard`: documented the effective runtime contract from official Anthropic/OpenAI sources and local evidence.
- `SyncOps`: published `full_operator_lane_sync.sh` to stop relying on ad hoc file copies.
- `PM-Mesh`: re-prioritized the next lot around staged-lane recovery on `clems` before resuming broader mesh propagation.
## Delta 2026-03-20 15:01 - plan de passe enchaînée (3 plans)
- `PM`: lot runbook exécuté `status→run→json`; les lots `zeroclaw-integrations`, `mesh-governance`, `mcp-runtime`, `cad-mcp-host` sont passés, `yiacad-fusion` bloque toujours sur contraintes d’intégration CAD prévues.
- `SyncOps`: préflight `mesh_health_check --load-profile tower-first --json` et `run_alignment_daily --mesh-load-profile tower-first` alignés avec ordre `clems, kxkm, cils, local, root`; `cils` reste en garde `cils-lockdown`.
- `Architect-Firmware`: carte de plans/compétences consolidée dans la section “Carte opérationnelle des 3 plans” pour mémoire d’exécution continue.
## Delta 2026-03-20 18:35 - canonical owners YiACAD
- `DesignOps-UI` garde le lead produit sur `T-UX-003` et `T-UX-004`.
- `CAD-UX / KiCad-Shell` devient owner de `T-UX-003A` pour les toolbars `pcbnew` / `eeschema`.
- `CAD-UX / FreeCAD-Shell` reste owner de `T-UX-003B` sur `yiacad_freecad_gui.py`.
- `CAD-UX / KiCad-Native` prend `T-UX-003C` pour la symetrie des control layers PCB/SCH.
- `CAD-UX / FreeCAD-Native` garde `T-UX-003D` comme prochaine tranche shell minimale sur `MainWindow.cpp`.
- `Doc-Research / OSS-Watch` prend `T-UX-004B` et la veille officielle associee.
- `SyncOps / TUI-Ops` prend `Support UI/UX Ops` pour la lisibilite de la lane, les preuves et les logs via `tools/cockpit/yiacad_uiux_tui.sh`.
## Delta 2026-03-20 16:05 - DesignOps UI/UX Apple-native
## Delta 2026-03-20 18:30 - Mascarade `kxkm-ai` live Ollama
- `Runtime-Companion`: le runtime live charge bien les `18` agents `kxkm-*` et s'appuie maintenant sur un `mascarade-ollama-runtime` local en `0.18.2`, raccorde au store de modeles deja presents sur `kxkm-ai`.
- `Provider-Bridge`: le catalogue `mascarade_model_profiles.kxkm_ai.json` passe en `ollama-first` pour eliminer la derive vers des providers externes non exposes par la stack live.
- `PM-Mesh`: nouveau lot `T-RE-218` ferme l'ecart entre catalogue, seed runtime et realite machine; smoke live confirme `kxkm-analysis` -> `ollama/mascarade-power:latest` et `kxkm-firmware` -> `ollama/mascarade-platformio:latest`.
- `Runtime-Smoke`: `T-RE-219` ajoute un smoke scriptable et logge pour la vague critique restante `code`, `cad`, `ops`, `fallback-safe`.
- `Runtime-Smoke`: le smoke consolide est valide via `artifacts/ops/mascarade_agent_smoke/latest.json`; `kxkm-analysis`, `kxkm-firmware`, `kxkm-code`, `kxkm-cad`, `kxkm-ops` et `kxkm-fallback-safe` repondent tous en `200` sur `ollama`.
- `Provider-Bridge`: le bridge utilisateur transitoire `kxkm-ollama-bridge.service` est maintenant desactive; la pile Mascarade live reste stable uniquement avec `mascarade-ollama-runtime`.
- `UI-Dispatch`: la page `Agents` de Mascarade expose maintenant des presets `kxkm-*` directement visibles et la publication front a ete regeneree dans `api/public`.
- `UX-Lead`: ouvre la refonte UI/UX YiACAD alignée sur les recommandations Apple officielles disponibles au 2026-03-20.
- `Apple-HIG`: tient la matrice `sidebar / toolbar / inspector / search / generative-ai affordances`.
## Delta 2026-03-20 18:25 - Mascarade kxkm-ai
- `Runtime-Companion`: a reutilise le chat Mascarade existant sur `kxkm-ai` au lieu de creer une nouvelle surcouche.
- `Provider-Bridge`: a seed 8 agents dynamiques `kxkm-*` dans `/home/kxkm/mascarade-main/data/agents.json` a partir du catalogue de profils runtime.
## Consolidation canonique 2026-03-20 - YiACAD
- Lanes de reference:
- `Audit-Core`: audit global, cartes, synthese
- `AI-Integration`: trajectoire IA, backend YiACAD, contexte unifie
- `CAD-Native`: hooks shells KiCad/FreeCAD, propagation de contexte
- `DesignOps-UI`: `T-UX-004`, palette, review center, inspector
- `Ops-TUI`: TUIs, logs, index operateur, preuves
- `Docs-Continuity`: README, index, plans, TODOs, coherence
- Canon current:
- `DesignOps-UI` garde le lead produit sur `T-UX-004`
- `CAD-Native` prend `T-ARCH-101` comme priorite architecture immediate
- `Ops-TUI` tient la convergence entre `yiacad_uiux_tui.sh` et `yiacad_refonte_tui.sh`
- Write-set architecture actif:
- `CAD-Native`: `tools/cad/yiacad_backend.py`, `tools/cad/yiacad_native_ops.py`
- `AI-Integration`: `specs/contracts/yiacad_context_broker.schema.json`, `specs/yiacad_backend_architecture_spec.md`
- `Docs-Continuity`: `docs/YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md`, `README.md`, `docs/index.md`
- Regle d'arbitrage:
- les affectations historiques restent valides comme trace
- les prochains write-sets YiACAD doivent se distribuer en priorite entre `backend`, `palette`, `review center`, `inspector`
## Delta 2026-03-20 18:35 - Mascarade kxkm-ai vague 2
- `Runtime-Companion`: etend le catalogue avec `firmware`, `cad`, `ops`, `docs`, `security`, `fine-tune`.
- `Provider-Bridge`: reutilise le meme seed `data/agents.json` pour densifier le chat existant sans nouvelle couche applicative.
## Delta 2026-03-20 18:45 - Mascarade kxkm-ai vague 3 + smoke
- `Runtime-Companion`: ajoute une vague metier `kill-life-firmware`, `yiacad-cad`, `mesh-syncops`, `docs-specs`.
- `Provider-Bridge`: confirme que le seed disque est bon mais que l'API live `127.0.0.1:3100/api/agents` ne remonte encore que les agents builtin; un reload runtime reste a programmer pour exposer les `kxkm-*` dans le chat actif.
- `CAD-UX`: porte la translation vers KiCad/FreeCAD (`plugin/workbench -> hooks directs -> shell natif`).
- `TUI-Ops`: publie la boucle `yiacad_uiux_tui.sh` avec lecture de logs, synthèse et purge contrôlée.
## Delta 2026-03-20 16:35 - T-UX-003 en cours
- `UX-Lead`: active le lot `T-UX-003` comme prochaine marche prioritaire de YiACAD.
- `KiCad-Native`: ownership de la montée shell côté `kicad-ki` via menus/toolbars/actions natives.
- `FreeCAD-Native`: ownership de la montée shell côté `freecad-ki` via workbench/manipulator/dock natifs.
- `Doc-Entry`: raccorde les docs d’entrée (`index`, `quickstart`, `runbook`, `MCP_SETUP`, `deploy/cad`) pour rendre les surfaces YiACAD découvrables.
## Delta 2026-03-20 16:55 - T-UX-003 palier 1 livré
- `KiCad-Native`: livre un premier palier dans `kicad_manager` avec `YiACAD Status` visible en menu et toolbar natifs.
- `FreeCAD-Native`: livre un premier palier avec `YiACAD Inspector` dockable dans `YiACADWorkbench`.
- `Doc-Entry`: a relié les docs opératoires et templates design à la lane YiACAD UI/UX.
- reste ouvert: montée native `pcbnew`, `eeschema`, palette de commandes et inspector plus profonds.
## Delta 2026-03-20 15:45 - registre canonique spec/module
- Canonique tri-repo publie dans `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`.
- `Kill_LIFE`:
- specs = ownership explicite `PM-Mesh`, `Arch-Mesh`, `Schema-Guard`, `QA-Compliance`, `Embedded-CAD`, `UX-Lead`
- modules = ownership explicite `SyncOps`, `Runtime-Companion`, `KillLife-Bridge`, `Release-Gates`
- `mascarade-main`:
- workstreams `WS0..WS9` ventiles entre `Runtime-Companion`, `SyncOps`, `Arch-Mesh`, `Web-Cockpit`
- `crazy_life-main`:
- workstreams `WS-01..WS-11` ventiles entre `Web-Cockpit`, `KillLife-Bridge`, `SyncOps`, `Docs-Research`
- Hotspots `single-writer` confirms:
- `tools/cockpit/mesh_sync_preflight.sh`
- `mascarade-main/api/src/lib/killlife.ts`
- `crazy_life-main/api/src/index.ts`
- `crazy_life-main/src/pages/CrazyLaneEditor.tsx`
- Nouvelle TUI:
- `bash tools/cockpit/agent_matrix_tui.sh --action summary`
- `bash tools/cockpit/agent_matrix_tui.sh --action owners`
- `bash tools/cockpit/agent_matrix_tui.sh --action open-tasks`
- Dirty-sets inter-machines realignes via `tools/cockpit/mesh_dirtyset_sync.sh`; le residuel `mesh_status=degraded` vient du `cils-lockdown` et non d'un ecart reel de worktree.
## Delta 2026-03-20 - coordination agents T-UX-003
- `DesignOps-UI` conserve le lead sur `T-UX-003` et prépare `T-UX-004`.
- `Sagan` est désormais owner du write-set `kicad-ki/kicad`, `kicad-ki/pcbnew`, `kicad-ki/eeschema` pour les insertions UI natives YiACAD.
- `Peirce` reste owner du write-set `freecad-ki/src/Mod/YiACADWorkbench` pour l'inspector, le docking et la montée vers des hooks plus profonds.
- Compétences actives sur le lot: intégration UI native, orchestration CAD IA, TUI cockpit, documentation de handoff.
## Delta 2026-03-20 - coordination agents direct hooks
- `Godel` a livré le recâblage direct `kicad-ki -> yiacad_native_ops.py` sur `kicad manager`, `pcbnew` et `eeschema`.
- `Locke` a livré le recâblage direct `freecad-ki -> yiacad_native_ops.py` dans le workbench `YiACADWorkbench`.
- `DesignOps-UI` peut maintenant déplacer la priorité de `wiring` vers `interaction design`, `feedback loops` et `palette/inspector orchestration`.
## Delta 2026-03-20 - distribution agents T-UX-004
- `DesignOps-UI` garde le lead fonctionnel sur `T-UX-004` et devient owner du contrat UX commun (`done|degraded|blocked`, severite, artefacts, next_steps).
- `Sagan/Godel lane` prend le write-set KiCad pour `palette` et `review center` sur `kicad manager`, `pcbnew`, `eeschema`.
- `Peirce/Locke lane` prend le write-set FreeCAD pour `palette`, `review center` et `inspector persistant` dans `YiACADWorkbench`.
- `AgentMatrix lane` garde la maintenance des plans, todos, competence maps et handoffs.
## Delta 2026-03-20 - agents refonte globale YiACAD
- `Audit-Core` prend ownership du bundle `docs/YIACAD_GLOBAL_*` et de `specs/yiacad_global_refonte_spec.md`.
- `AI-Integration` prend ownership de la matrice d'opportunites IA et de la veille OSS associee.
- `Ops-TUI` prend ownership de `tools/cockpit/yiacad_refonte_tui.sh` et de `artifacts/yiacad_refonte_tui/*`.
- `DesignOps-UI` conserve le lead sur `T-UX-004` et depend des sorties du bundle global pour la priorisation UX.
## Delta 2026-03-21 - operator index lane
- `Ops-TUI` prend l'ownership de l'entree operateur stable:
- `docs/YIACAD_OPERATOR_INDEX_2026-03-21.md`
- `tools/cockpit/yiacad_operator_index.sh`
- `DesignOps-UI` garde le lead produit sur la suite de `T-UX-004`.
## Delta 2026-03-21 - T-UX-005 execution
- `Newton` a livre l'enrichissement du review center cote plugin KiCad.
- `Hypatia` a livre l'enrichissement du review center cote workbench FreeCAD.
- `DesignOps-UI` garde maintenant comme front principal `T-UX-006` pour l'inspector persistant.
## Delta 2026-03-21 - T-UX-006 execution
- `Franklin` a livre la persistance de session cote plugin KiCad.
- `Lorentz` a livre la persistance de session cote workbench FreeCAD.
- `DesignOps-UI` peut maintenant deplacer le focus produit vers une session de revue plus riche, tandis que `CAD-Native` garde `T-ARCH-101C` comme front architecture.
## Delta 2026-03-21 - T-ARCH-101C execution
- `Hume` a recable le plugin KiCad sur `yiacad_backend_client.py` en mode `service-first` avec fallback direct.
- `Mendel` a recable le workbench FreeCAD sur `yiacad_backend_client.py` en mode `service-first` avec fallback direct.
- `CAD-Native` garde maintenant comme suite logique l'extension du chemin service-first aux surfaces plus profondes si necessaire.
## 2026-03-21 - Lot update
- `T-ARCH-101C` etendu: les surfaces KiCad compilees passent en `service-first` via `tools/cad/yiacad_backend_client.py`, avec auto-start du service local et fallback direct vers `tools/cad/yiacad_native_ops.py`.
- `T-OPS-119` consolide: `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable avec `status`, `uiux`, `global`, `backend`, `proofs` et des alias de compatibilite conserves.
- Risque residuel: aucune validation d'execution n'a ete lancee; l'extension aux call sites compiles restants doit etre traitee dans un lot separe.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
## 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 - Tower Mascarade runtime / dispatch
- `Runtime-Companion` prend l'ownership de:
- `specs/contracts/mascarade_model_profiles.tower.json`
- `tools/ops/sync_mascarade_agents_tower.sh`
- `tools/ops/deploy_mascarade_tower_runtime.sh`
- `SyncOps` prend l'ownership de:
- `specs/contracts/mascarade_dispatch.mesh.json`
- `tools/cockpit/mascarade_dispatch_mesh.sh`
- `Docs-Research` publie:
- `docs/MASCARADE_TOWER_RUNTIME_2026-03-21.md`
- Politique agentique retenue:
- `tower-code`, `tower-analysis`, `tower-research` = lanes lourdes prioritaires sur `tower`
- `tower-text` = lane documentaire secondaire `tower`, fallback `kxkm`
- `kxkm-*` reste la couche interactive/orchestration et le premier fallback operable
## Delta 2026-03-21 - consolidation produit ops / Mascarade / kill_life
- `PM-Mesh` prend l'ownership du contrat produit commun:
- `specs/contracts/ops_mascarade_kill_life.contract.json`
- `docs/OPS_MASCARADE_KILL_LIFE_PRODUCT_CONTRACT_2026-03-21.md`
- `SyncOps` devra projeter ce contrat dans les sorties cockpit prioritaires.
- `Runtime-Companion` devra exposer `routing` et `trust_level` cote Mascarade.
- `KillLife-Bridge` devra materialiser `resume_ref` et `memory_entry` comme traces de continuite d'execution.
## Delta 2026-03-21 - projection contrat sur les surfaces cockpit
- `SyncOps` prend l'ownership de:
- `tools/cockpit/full_operator_lane.sh`
- `tools/cockpit/run_alignment_daily.sh`
- `KillLife-Bridge` prend l'ownership de:
- `tools/cockpit/write_kill_life_memory_entry.sh`
- objectif atteint sur ce lot:
- `owner`, `decision`, `resume_ref`, `trust_level`, `routing` et `memory_entry` remontent dans les JSON cockpit prioritaires
- une memoire `kill_life` timestampée et `latest` est ecrite dans `artifacts/cockpit/kill_life_memory`
## Delta 2026-03-21 - projection contrat sur les surfaces Mascarade et handoffs
- `Runtime-Companion` prend l'ownership de:
- `tools/cockpit/mascarade_runtime_health.sh`
- `tools/cockpit/mascarade_incidents_tui.sh`
- `Docs-Research` prend l'ownership de:
- `tools/cockpit/render_daily_operator_summary.sh`
- `tools/cockpit/render_weekly_refonte_summary.sh`
- objectif atteint sur ce lot:
- les surfaces Mascarade courtes relisent la memoire `kill_life`
- les handoffs Markdown quotidiens et hebdomadaires rendent explicites `trust_level`, `resume_ref` et la cible de routing
## Delta 2026-03-21 - micro-surfaces Mascarade
- `Runtime-Companion` prend aussi l'ownership de:
- `tools/cockpit/render_mascarade_incident_brief.sh`
- `tools/cockpit/render_mascarade_incident_queue.sh`
- `tools/cockpit/render_mascarade_incident_watch.sh`
- `tools/cockpit/render_mascarade_watch_history.sh`
- objectif atteint:
- les resumes Mascarade les plus courts gardent eux aussi la continuite `kill_life`
## Delta 2026-03-21 - veille mémoire agentique
- `Docs-Research` consolide la veille dans:
- `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`
- décision de plan:
- garder la mémoire `latest` fichier tant que le contrat produit n'est pas gelé
- n'ouvrir un vrai store mémoire agentique qu'après stabilisation de `resume_ref`, `trust_level`, `routing` et `memory_entry`
## Delta 2026-03-21 - writer kill_life et dernières surfaces
- `KillLife-Bridge` corrige `tools/cockpit/write_kill_life_memory_entry.sh` pour transmettre réellement les artefacts de reprise.
- `Runtime-Companion` étend la projection contrat à:
- `tools/cockpit/mascarade_incident_registry.sh`
- `tools/cockpit/mascarade_logs_tui.sh`
- objectif atteint:
- la mémoire `kill_life` latest devient cohérente avec les surfaces de logs et d'incidents
## Delta 2026-03-21 - gouvernance / points d'entrée
- `Ops-TUI` étend les points d'entrée vers:
- `tools/cockpit/yiacad_operator_index.sh`
- `Docs-Research` et `PM-Mesh` étendent la convergence vers:
- `tools/cockpit/intelligence_tui.sh`
- objectif atteint:
- les entrées opérateur et la mémoire de gouvernance pointent elles aussi vers la continuité `kill_life`
## Delta 2026-03-21 - chaînes de pilotage cockpit
- `Ops-TUI` étend la continuité `kill_life` vers:
- `tools/cockpit/refonte_tui.sh`
- `tools/cockpit/lot_chain.sh`
- `PM-Mesh` garde l'ownership du fil conducteur entre:
- `artifacts/cockpit/kill_life_memory/latest.json`
- `artifacts/cockpit/useful_lots_status.md`
- `specs/03_plan.md`
- `specs/04_tasks.md`
- objectif atteint:
- la TUI courte et la chaîne de lots cockpit convergent elles aussi vers le même point de reprise
## Delta 2026-03-21 - audit et cartographie du contrat produit
- `PM-Mesh` prend l'ownership de:
- `tools/cockpit/product_contract_audit.sh`
- `docs/OPS_MASCARADE_KILL_LIFE_FEATURE_MAP_2026-03-21.md`
- `Docs-Research` consolide la veille officielle dans:
- `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`
- objectif atteint:
- un garde-fou statique contrôle la présence des ancrages de continuité dans les surfaces source
- la carte Mermaid rend explicite la séparation `ops / Mascarade / kill_life` et leur point de convergence
## Delta 2026-03-21 - handoff produit minimal
- `Ops-TUI` prend l'ownership de:
- `tools/cockpit/render_product_contract_handoff.sh`
- `Docs-Research` consolide le rationnel HITL / reprise dans:
- `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`
- objectif atteint:
- un brief opérateur unique agrège audit, mémoire `kill_life` et synthèse quotidienne
- le prochain pas produit reste lisible sans changer de surface
## Delta 2026-03-21 - handoff produit degraded-safe
- `Ops-TUI` durcit `tools/cockpit/render_product_contract_handoff.sh`.
- `PM-Mesh` conserve l'ownership des critères de sincérité:
- pas de statut `ok` si la mémoire `kill_life` latest ou la synthèse quotidienne manquent
- objectif atteint:
- le handoff produit devient un vrai garde-fou opérateur, même en absence d'artefacts amont
## Delta 2026-03-21 - handoff produit self-healing et exposition opérateur
- `KillLife-Bridge` prend l'ownership de:
- l'auto-régénération légère dans `tools/cockpit/render_product_contract_handoff.sh`
- `SyncOps` prend l'ownership de:
- l'intégration du handoff dans `tools/cockpit/run_alignment_daily.sh`
- l'intégration du handoff dans `tools/cockpit/full_operator_lane.sh`
- `Ops-TUI` prend l'ownership de:
- l'exposition du handoff dans `tools/cockpit/yiacad_operator_index.sh`
- l'exposition du handoff dans `tools/cockpit/refonte_tui.sh`
- `Docs-Research` consolide:
- `tools/cockpit/README.md`
- objectif atteint:
- le handoff produit devient le point de reprise canonique visible depuis les chemins opérateur
- la séparation entre audit statique et handoff runtime léger reste explicite
## Delta 2026-03-21 - correctifs producteurs du handoff
- `KillLife-Bridge` corrige `tools/cockpit/write_kill_life_memory_entry.sh`.
- `Docs-Research` corrige la sortie JSON unique de `tools/cockpit/render_daily_operator_summary.sh`.
- objectif atteint:
- le self-healing du handoff peut réellement recréer sa mémoire `kill_life`
- le résumé quotidien reste parseable en JSON par les autres surfaces
## Delta 2026-03-21 - propagation Markdown du handoff
- `Ops-TUI` corrige le contrat de `tools/cockpit/render_product_contract_handoff.sh`.
- objectif atteint:
- `markdown_file` et `latest_markdown_file` remontent explicitement dans le JSON du handoff
- les surfaces opérateur qui relisent ce handoff retrouvent un pointeur Markdown exploitable
## Delta 2026-03-21 - robustesse JSON lane opérateur
- `SyncOps` durcit `tools/cockpit/full_operator_lane.sh`.
- objectif atteint:
- la lecture d'artefacts JSON concaténés ne casse plus la lane opérateur
- les régressions liées à des payloads historiques multi-JSON sont contenues dans le helper de lecture
## Delta 2026-03-21 - T-UX-003 / T-UX-004 closure
- `DesignOps-UI` clot les lots parents `T-UX-003` et `T-UX-004` apres verification des surfaces reelles KiCad/FreeCAD.
- `CAD-UX / KiCad-Shell`, `CAD-UX / KiCad-Native`, `CAD-UX / FreeCAD-Shell` et `CAD-UX / FreeCAD-Native` basculent leur front restant vers `T-UX-007`.
- `QA-Compliance` ajoute `test/test_yiacad_native_surface_contract.py` pour verrouiller la presence des ancrages shell, de la palette et de l'inspector persistant.
## Session 2026-03-22 — ERP minimal / bridge Ops -> Kill_LIFE
Nouveaux agents dedies ou reaffectes:
- `Ops-Governor` -> couche `ERP / L'electronrare Ops`, gouvernance machines, roots, secret scopes, ownership
- `KillLife-Bridge` -> pont secrets de gouvernance et continuite outillage `Kill_LIFE`
- `Artifact-Curator` -> couche `WMS`, index artefacts / logs / datasets / handoffs
- `Runtime-Guard` -> couche `DCS`, health-checks, mesh, dispatch, charge
- `PLM-Archivist` -> couche `PLM`, contrats, plans, cartes systeme
- `Dataset-Curator` -> preflight dataset et blocages VM fine-tune
Livrables rattaches:
- `docs/OPS_KILL_LIFE_ERP_BRIDGE_CONTRACT_2026-03-22.md`
- `specs/contracts/ops_kill_life_erp_registry.json`
- `tools/cockpit/ops_erp_registry_tui.sh`
- `docs/WEB_RESEARCH_DIGITAL_FACTORY_STACK_2026-03-22.md`
## Session 2026-03-22 — WMS artifact index minimal
Affectations confirmees:
- `Artifact-Curator` -> proprietaire de l'index `artifact -> lot -> couche -> consumer`
- `SyncOps` -> consumer principal cote `MES`
- `Runtime-Guard` -> consumer principal cote `DCS`
- `PLM-Archivist` -> consumer principal cote `PLM`
Livrables rattaches:
- `specs/contracts/artifact_wms_index_rules.json`
- `tools/cockpit/artifact_wms_index_tui.sh`
- `docs/ARTIFACT_WMS_INDEX_2026-03-22.md`
- `Artifact-Curator` and `Ops-Governor` now also own the comparative reference set for WMS indexing and future cockpit catalog patterns (`MLflow`, `Dagster`, `DVC`, `Backstage`, `Rundeck`).
## Delta 2026-03-22 - PCB AI / fabrication ownership
- `Embedded-CAD` prend l'ownership du cadrage externe `PCB Designer AI / Quilter` pour les lanes de layout et de fabrication.
- `CAD-Bridge` prend la future lane `T-RE-296` de round-trip `KiCad -> Quilter -> preuves locales`.
- `HW-BOM` prend l'ownership des patterns `BOM / sourcing / JLCPCB / LCSC` issus de `kicad-happy`.
- `Forge` devient copilote de traduction des patterns `review.bom`, `alternatives composants`, `fabrication prep` vers les playbooks locaux.
- `CAD-Smoke` garde la responsabilite des preuves de canary et des criteres d'acceptation avant toute adoption runtime.
## Delta 2026-03-22 - realignment lot 26 + fab package ownership
- `PM-Mesh / Todo-Tracker` prend l'ownership du realignement de `Plan 26` et des ecarts doc vs repo actif.
- `Embedded-CAD` prend l'ownership du contrat `fab package` et de l'orchestration locale `BOM + DRC + Gerber/drill + provenance`.
- `SyncOps / TUI-Ops` prend l'ownership de `tools/cockpit/fab_package_tui.sh` et des artefacts `latest.json` / `latest.md`.
- `HW-BOM` porte la sortie `assembly-ready|blocked`, les alternatives composants et le mapping `LCSC/JLCPCB`.
- `Runtime-Companion` ne reprend la main sur les providers/agents EDA que lorsque le realignement lot 26 est clos et que le contrat `fab package` est valide.
docs/plans/16_plan_cad_modeling_stack.md
+6
View File
@@ -20,6 +20,11 @@ Faire de `Kill_LIFE` la source de verite operateur pour une stack modelling loca
Le lot couvre la couche locale non-MCP. Les serveurs MCP dedies sont suivis dans le backlog cible `MCP` / `agentics`.
Important:
- ce plan couvre la stack modelling locale `FreeCAD/OpenSCAD` hors shell GUI YiACAD;
- les surfaces GUI natives KiCad/FreeCAD et la refonte UI/UX Apple-native sont suivies dans `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`.
## Etat actuel
- `FreeCAD` est supporte en headless via `freecadcmd`
@@ -34,6 +39,7 @@ Le lot couvre la couche locale non-MCP. Les serveurs MCP dedies sont suivis dans
- `FreeCAD` et `OpenSCAD` sont supportes en headless local
- ce lot reste distinct de `mcp_tasks.md`
- la suite MCP se traite dans `specs/mcp_agentics_target_backlog.md`
- la couche GUI YiACAD est geree separement et ne remet pas en cause ce contrat headless
## Resultat v1 livre
docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md
+274 -3
View File
@@ -1,9 +1,18 @@
# 18) Plan d'enchainement autonome des lots utiles
Last updated: 2026-03-09 09:24:59
Last updated: 2026-03-21 15:02:39
Ce plan est regenere localement par `tools/autonomous_next_lots.py`.
## Cycle lot opérationnel
1. detection: `bash tools/run_autonomous_next_lots.sh status`
2. run: `bash tools/run_autonomous_next_lots.sh run`
3. proof JSON: `bash tools/run_autonomous_next_lots.sh json`
4. mise a jour plan/todo
5. revue owner + routing lot suivant
6. synthese operateur + lot exit checklist
## Objectif
Detecter les deltas utiles a traiter, prioriser le prochain lot executable,
@@ -19,27 +28,288 @@ mettre a jour un plan/todo operateur, puis relancer les validations associees.
## Etat Git courant
- branche: `## main...origin/main`
- dirty paths: `6`
- dirty paths: `179`
- ahead: `0`
- behind: `0`
### Fichiers dirty detectes
- `.github/workflows/repo_state_header_gate.yml`
- `README.md`
- `SYNTHESE_AGENTIQUE.md`
- `ai-agentic-embedded-base/specs/00_intake.md`
- `ai-agentic-embedded-base/specs/01_spec.md`
- `ai-agentic-embedded-base/specs/02_arch.md`
- `ai-agentic-embedded-base/specs/03_plan.md`
- `ai-agentic-embedded-base/specs/04_tasks.md`
- `ai-agentic-embedded-base/specs/README.md`
- `ai-agentic-embedded-base/specs/zeroclaw_dual_hw_orchestration_spec.md`
- `ai-agentic-embedded-base/specs/zeroclaw_dual_hw_todo.md`
- `deploy/cad/README.md`
- `docs/AGENTIC_LANDSCAPE.md`
- `docs/AI_WORKFLOWS.md`
- `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
- `docs/MCP_SETUP.md`
- `docs/QUICKSTART.md`
- `docs/REPO_STATE.md`
- `docs/REPO_STATE_HEADER_CONTRACT.md`
- `docs/RUNBOOK.md`
- `docs/handoffs/handoff_design.md`
- `docs/index.md`
- `docs/plans/12_plan_gestion_des_agents.md`
- `docs/plans/16_plan_cad_modeling_stack.md`
- `docs/plans/README.md`
- `docs/plans/REPO_DEEP_ANALYSIS_2026-03-11.md`
- `docs/repo_state.json`
- `docs/templates/DesignReview.md`
- `docs/templates/PlaytestReport.md`
- `specs/00_intake.md`
- `specs/01_spec.md`
- `specs/02_arch.md`
- `specs/03_plan.md`
- `specs/04_tasks.md`
- `specs/README.md`
- `specs/zeroclaw_dual_hw_orchestration_spec.md`
- `specs/zeroclaw_dual_hw_todo.md`
- `tools/ai/integrations/n8n/README.md`
- `tools/ai/integrations/n8n/kill_life_smoke_workflow.json`
- `tools/ai/zeroclaw_dual_bootstrap.sh`
- `tools/ai/zeroclaw_dual_chat.sh`
- `tools/ai/zeroclaw_hw_firmware_loop.sh`
- `tools/ai/zeroclaw_integrations_down.sh`
- `tools/ai/zeroclaw_integrations_import_n8n.sh`
- `tools/ai/zeroclaw_integrations_lot.sh`
- `tools/ai/zeroclaw_integrations_status.sh`
- `tools/ai/zeroclaw_integrations_up.sh`
- `tools/ai/zeroclaw_stack_up.sh`
- `tools/auto_check_ci_cd.py`
- `tools/autonomous_next_lots.py`
- `tools/bootstrap_mac_mcp.sh`
- `tools/cockpit/README.md`
- `tools/cockpit/cockpit.py`
- `tools/cockpit/lot_chain.sh`
- `tools/cockpit/run_next_lots_autonomously.sh`
- `tools/github_dispatch_mcp.py`
- `tools/hw/cad_stack.sh`
- `tools/hw/hw_diff.py`
- `tools/hw/kicad_host_mcp_smoke.py`
- `tools/hw/run_kicad_mcp.sh`
- `tools/knowledge_base_mcp.py`
- `tools/lib/runtime_home.sh`
- `tools/repo_state/lint_header_contract.py`
- `tools/repo_state/repo_refresh.sh`
- `tools/run_github_dispatch_mcp.sh`
- `tools/run_knowledge_base_mcp.sh`
- `tools/test_python.sh`
- `.github/workflows/docs_reference_gate.yml`
- `.github/workflows/mesh_contracts.yml`
- `.platformio-local/`
- `ai-agentic-embedded-base/specs/agentic_intelligence_integration_spec.md`
- `ai-agentic-embedded-base/specs/contracts/`
- `ai-agentic-embedded-base/specs/mesh_contracts.md`
- `ai-agentic-embedded-base/specs/yiacad_backend_architecture_spec.md`
- `ai-agentic-embedded-base/specs/yiacad_global_refonte_spec.md`
- `ai-agentic-embedded-base/specs/yiacad_tux004_orchestration_spec.md`
- `ai-agentic-embedded-base/specs/yiacad_uiux_apple_native_spec.md`
- `docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-21.md`
- `docs/AGENT_MODULE_ASSIGNMENTS_2026-03-20.md`
- `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
- `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`
- `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`
- `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md`
- `docs/FULL_OPERATOR_LANE_2026-03-20.md`
- `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md`
- `docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md`
- `docs/MACHINE_REGISTRY_2026-03-20.md`
- `docs/MACHINE_SYNC_STATUS_2026-03-20.md`
- `docs/MASCARADE_MODEL_PROFILES_KXKM_AI_2026-03-20.md`
- `docs/MASCARADE_OPS_OBSERVABILITY_FEATURE_MAP_2026-03-21.md`
- `docs/MASCARADE_TOWER_RUNTIME_2026-03-21.md`
- `docs/MESH_DIRTYSET_CLEANUP_2026-03-20.md`
- `docs/MESH_SYNC_INCIDENT_REGISTER_2026-03-20.md`
- `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`
- `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`
- `docs/REFACTOR_MANIFEST_2026-03-20.md`
- `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md`
- `docs/WEB_RESEARCH_AGENTIC_STACK_2026-03-20.md`
- `docs/WEB_RESEARCH_MASCARADE_OBSERVABILITY_2026-03-21.md`
- `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_FEATURE_MAP_2026-03-20.md`
- `docs/YIACAD_APPLE_UI_UX_OSS_RESEARCH_2026-03-20.md`
- `docs/YIACAD_AUTONOMOUS_LOT_CHAIN_2026-03-21.md`
- `docs/YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md`
- `docs/YIACAD_BACKEND_OPERATOR_PROOF_2026-03-21.md`
- `docs/YIACAD_BACKEND_SERVICE_2026-03-21.md`
- `docs/YIACAD_EXHAUSTIVE_REFOUNTE_AUDIT_2026-03-20.md`
- `docs/YIACAD_GLOBAL_AI_INTEGRATION_ASSESSMENT_2026-03-20.md`
- `docs/YIACAD_GLOBAL_FEATURE_MAP_2026-03-20.md`
- `docs/YIACAD_GLOBAL_OSS_RESEARCH_2026-03-20.md`
- `docs/YIACAD_GLOBAL_REFACTOR_AUDIT_2026-03-20.md`
- `docs/YIACAD_NATIVE_UI_INSERTION_POINTS_2026-03-20.md`
- `docs/YIACAD_OPERATOR_INDEX_2026-03-21.md`
- `docs/YIACAD_OPERATOR_LOG_CONTRACT_2026-03-21.md`
- `docs/YIACAD_PROOFS_TUI_2026-03-21.md`
- `docs/YIACAD_REVIEW_SESSION_2026-03-21.md`
- `docs/YIACAD_TUX004_FEATURE_MAP_2026-03-20.md`
- `docs/YIACAD_UIUX_OUTPUT_CONTRACT_2026-03-20.md`
- `docs/plans/19_todo_mesh_tri_repo.md`
- `docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md`
- `docs/plans/20_todo_refonte_ui_ux_yiacad_apple_native.md`
- `docs/plans/21_plan_refonte_globale_yiacad.md`
- `docs/plans/21_todo_refonte_globale_yiacad.md`
- `docs/plans/22_plan_integration_intelligence_agentique.md`
- `docs/plans/22_todo_integration_intelligence_agentique.md`
- `specs/agentic_intelligence_integration_spec.md`
- `specs/contracts/`
- `specs/mesh_contracts.md`
- `specs/yiacad_backend_architecture_spec.md`
- `specs/yiacad_global_refonte_spec.md`
- `specs/yiacad_tux004_orchestration_spec.md`
- `specs/yiacad_uiux_apple_native_spec.md`
- `test/test_intelligence_tui_contract.py`
- `test/test_log_ops_contract.py`
- `test/test_machine_registry_contract.py`
- `test/test_runtime_ai_gateway_contract.py`
- `test/test_yiacad_native_surface_contract.py`
- `test/test_yiacad_uiux_tui_contract.py`
- `test/test_zeroclaw_n8n_workflow_contract.py`
- `tools/cad/`
- `tools/cockpit/agent_matrix_tui.sh`
- `tools/cockpit/full_operator_lane.sh`
- `tools/cockpit/full_operator_lane_sync.sh`
- `tools/cockpit/intelligence_program_tui.sh`
- `tools/cockpit/intelligence_tui.sh`
- `tools/cockpit/json_contract.sh`
- `tools/cockpit/log_ops.sh`
- `tools/cockpit/machine_registry.sh`
- `tools/cockpit/mascarade_dispatch_mesh.sh`
- `tools/cockpit/mascarade_incident_registry.sh`
- `tools/cockpit/mascarade_incidents_tui.sh`
- `tools/cockpit/mascarade_logs_tui.sh`
- `tools/cockpit/mascarade_models_tui.sh`
- `tools/cockpit/mascarade_runtime_health.sh`
- `tools/cockpit/mesh_dirtyset_sync.sh`
- `tools/cockpit/mesh_health_check.sh`
- `tools/cockpit/mesh_sync_preflight.sh`
- `tools/cockpit/refonte_tui.sh`
- `tools/cockpit/render_daily_operator_summary.sh`
- `tools/cockpit/render_mascarade_incident_brief.sh`
- `tools/cockpit/render_mascarade_incident_queue.sh`
- `tools/cockpit/render_mascarade_incident_watch.sh`
- `tools/cockpit/render_mascarade_watch_history.sh`
- `tools/cockpit/render_weekly_refonte_summary.sh`
- `tools/cockpit/run_alignment_daily.sh`
- `tools/cockpit/runtime_ai_gateway.sh`
- `tools/cockpit/ssh_healthcheck.sh`
- `tools/cockpit/yiacad_backend_proof.sh`
- `tools/cockpit/yiacad_backend_service_tui.sh`
- `tools/cockpit/yiacad_logs_tui.sh`
- `tools/cockpit/yiacad_operator_index.sh`
- `tools/cockpit/yiacad_proofs_tui.sh`
- `tools/cockpit/yiacad_refonte_tui.sh`
- `tools/cockpit/yiacad_uiux_tui.sh`
- `tools/ops/`
- `tools/specs/mesh_contract_check.py`
- `workflows/embedded-operator-live.json`
## Gouvernance intelligence
- status: `done`
- open_task_count: `0`
- memory: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/artifacts/cockpit/intelligence_program/latest.json`
- next actions:
- No open tasks detected in docs/plans/22_todo_integration_intelligence_agentique.md.
## Matrice lot -> owner -> dépendances -> rollback
## Lots detectes
### 1. `zeroclaw-integrations` — Runtime local ZeroClaw / n8n
- owner: team=PM, agent=PM-Mesh, repo=Kill_LIFE
- dependencies: `none`
- rollback:
- Revenir à la lane `zeroclaw` manuelle si le container n8n échoue de manière persistante.
- Rejouer `bash tools/run_autonomous_next_lots.sh run --no-write` puis arbitrer manuellement.
Fermer la lane d'integrations locales ZeroClaw/n8n, les evidences I-205 associees, puis resynchroniser les plans versionnes d'enchainement autonome et le cockpit local.
- references: `specs/zeroclaw_dual_hw_todo.md`, `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
- validations: `2` done, `0` advisory, `0` blocked
- handoff: lot_id=zeroclaw-integrations, owner_repo=Kill_LIFE, owner_agent=PM-Mesh, owner_subagent=none, status=done
- write_set: specs/zeroclaw_dual_hw_todo.md, tools/cockpit/lot_chain.sh, tools/cockpit/run_next_lots_autonomously.sh
### 2. `mesh-governance` — Gouvernance mesh tri-repo
- owner: team=PM, agent=PM-Mesh, repo=Kill_LIFE
- dependencies: `zeroclaw-integrations`
- rollback:
- Retirer le lot `mesh-governance` du déclenchement auto si la convergence reste bloquée.
- Conserver le contrat mesh en mode lecture seule et documenter la dérogation.
Versionner le contrat tri-repo, verrouiller les ownerships agents, et outiller le preflight de synchro continue sans ecraser le travail des autres contributeurs.
- references: `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md`, `docs/plans/12_plan_gestion_des_agents.md`, `specs/03_plan.md`
- validations: `5` done, `0` advisory, `0` blocked
- handoff: lot_id=mesh-governance, owner_repo=Kill_LIFE, owner_agent=PM-Mesh, owner_subagent=none, status=done
- write_set: docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md, docs/MACHINE_SYNC_STATUS_2026-03-20.md, docs/plans/19_todo_mesh_tri_repo.md, tools/cockpit/mesh_sync_preflight.sh, tools/cockpit/ssh_healthcheck.sh
### 3. `mcp-runtime` — Alignement MCP runtime local
- owner: team=Architect-Firmware, agent=Runtime-Companion, repo=Kill_LIFE
- dependencies: `zeroclaw-integrations`
- rollback:
- Désactiver les changements MCP introduits dans le lot et revenir à la configuration de référence.
- Conserver la preuve de doc dans `docs/MCP_SETUP.md` et relancer uniquement en mode validation.
Stabiliser les launchers MCP, le bootstrap Mac, la resolution du repo compagnon et la doc operateur associee.
- references: `docs/plans/15_plan_mcp_runtime_alignment.md`, `docs/plans/17_plan_target_architecture_mcp_agentics_2028.md`
- validations: `3` done, `2` advisory, `0` blocked
- handoff: lot_id=mcp-runtime, owner_repo=Kill_LIFE, owner_agent=Runtime-Companion, owner_subagent=none, status=degraded
- write_set: docs/MCP_SETUP.md, tools/bootstrap_mac_mcp.sh, tools/lib/runtime_home.sh, tools/run_github_dispatch_mcp.sh
### 4. `cad-mcp-host` — Runtime CAD host-first
- owner: team=Architect-Firmware, agent=Embedded-CAD, repo=Kill_LIFE
- dependencies: `mcp-runtime`
- rollback:
- Retour automatique au mode container-only (`tools/hw/cad_stack.sh`).
- Conserver les chemins explicites de script pour éviter une dérive host-first.
Qualifier KiCad, FreeCAD et OpenSCAD en host-first sur macOS tout en gardant le fallback conteneur operable.
- references: `docs/plans/16_plan_cad_modeling_stack.md`, `docs/plans/17_plan_target_architecture_mcp_agentics_2028.md`
- validations: `4` done, `0` advisory, `0` blocked
- handoff: lot_id=cad-mcp-host, owner_repo=Kill_LIFE, owner_agent=Embedded-CAD, owner_subagent=none, status=done
- write_set: docs/MCP_SETUP.md, tools/hw/cad_stack.sh, tools/hw/run_kicad_mcp.sh
### 5. `yiacad-fusion` — Fusion KiCad + FreeCAD IA-native
- owner: team=CAD-Fusion, agent=CAD-Fusion, repo=Kill_LIFE
- dependencies: `cad-mcp-host`
- rollback:
- Geler la branche `kill-life-ai-native` et revenir au mode container-only (`tools/hw/cad_stack.sh`).
- Conserver les artefacts YiACAD (`artifacts/cad-fusion`) et la synthese hebdomadaire comme preuve.
- Basculer l'execution en mode `status` + `clean-logs` si le smoke bloque.
Mettre en place le lot YiACAD (`prepare`, `smoke`, `status`, `logs`, `clean-logs`) et la synthese operateur associee sans fusion automatique de `main`.
- references: `docs/CAD_AI_NATIVE_FORK_STRATEGY.md`, `docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md`, `docs/plans/18_todo_enchainement_autonome_des_lots_utiles.md`
- validations: `2` done, `1` advisory, `0` blocked
- handoff: lot_id=yiacad-fusion, owner_repo=Kill_LIFE, owner_agent=CAD-Fusion, owner_subagent=none, status=degraded
- write_set: docs/CAD_AI_NATIVE_FORK_STRATEGY.md, docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md, tools/cad/ai_native_forks.sh, tools/cad/yiacad_fusion_lot.sh, tools/cockpit/refonte_tui.sh, tools/cockpit/render_weekly_refonte_summary.sh
### 6. `python-local` — Execution Python repo-locale
- owner: team=Architect-Firmware, agent=Firmware, repo=Kill_LIFE
- dependencies: `mcp-runtime`, `cad-mcp-host`
- rollback:
- Revenir à l'exécution Python système si la venv locale est instable.
- Limiter les changements au lot `tools/test_python.sh` jusqu'à stabilisation.
Garder les scripts et smokes sur l'interpreteur repo-local plutot que sur le Python systeme.
- references: `docs/plans/15_plan_mcp_runtime_alignment.md`
- validations: `1` done, `0` advisory, `0` blocked
- handoff: lot_id=python-local, owner_repo=Kill_LIFE, owner_agent=Firmware, owner_subagent=none, status=done
- write_set: tools/test_python.sh, tools/run_validate_specs_mcp.sh, tools/validate_specs_mcp_smoke.py
## Questions a poser seulement si besoin reel
@@ -50,4 +320,5 @@ Fermer la lane d'integrations locales ZeroClaw/n8n, les evidences I-205 associee
- `bash tools/run_autonomous_next_lots.sh status`
- `bash tools/run_autonomous_next_lots.sh run`
- `bash tools/run_autonomous_next_lots.sh json`
- `bash tools/cockpit/render_weekly_refonte_summary.sh`
docs/plans/18_todo_enchainement_autonome_des_lots_utiles.md
+108 -3
View File
@@ -1,14 +1,119 @@
# 18) TODO enchainement autonome des lots utiles
Last updated: 2026-03-09 09:24:59
Last updated: 2026-03-21 15:02:39
Ce fichier est regenere localement par `tools/autonomous_next_lots.py`.
## `intelligence-governance`
- status: done
- open_task_count: 0
- next: No open tasks detected in docs/plans/22_todo_integration_intelligence_agentique.md.
- evidence: /Users/electron/Documents/Lelectron_rare/Kill_LIFE/artifacts/cockpit/intelligence_program/latest.json
## `zeroclaw-integrations` — Runtime local ZeroClaw / n8n
- done: lot detecte (Fermer la lane d'integrations locales ZeroClaw/n8n, les evidences I-205 associees, puis resynchroniser les plans versionnes d'enchainement autonome et le cockpit local.)
- done: `bash tools/ai/zeroclaw_integrations_lot.sh verify --json`
resume: {"lot_id": "zeroclaw-integrations-n8n", "syntax_ok": true, "status": {"container": "mascarade-n8n", "container_exists": true, "container_running": true, "container_status": "Up 19 hours (healthy)", "internal_http_ok": true, "host_http_ok": true, "n8n_url": "http://127.0.0.1:5678/", "workflow_ids": ["kill-life-n8n-smoke"], "active_workflow_ids": ["kill-life-n8n-smoke"]}, "import": {"workflow_id": "kill-life-n8n-smoke", "input_file": "/home/clems/Kill_LIFE/tools/ai/integrations/n8n/kill_life_smoke_workflow.json", "container": "mascarade-n8n", "import_action": "skipped", "publish_action": "published", "active": true}}
resume: {"lot_id": "zeroclaw-integrations-n8n", "syntax_ok": true, "overall_status": "ready", "blockers": [], "status": {"status": "ready", "reason": "", "container": "mascarade-n8n", "container_exists": true, "container_running": true, "container_status": "Up 3 minutes", "internal_http_ok": true, "host_http_ok": true, "n8n_url": "http://127.0.0.1:5678/", "n8n_health_url": "http://127.0.0.1:5678/healthz", "tracked_workflow_id": "kill-life-n8n-smoke", "runtime_alerts": [], "workflow_probe_status": "not_queried", "active_probe_status": "not_queried", "workflow_ids": [], "active_workflow_ids": []}, "import": {"workflow_id": "kill-life-n8n-smoke", "input_file": "/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/ai/integrations/n8n/kill_life_smoke_workflow.json", "container": "mascarade-n8n", "import_action": "skipped", "publish_action": "skipped", "active": true}}
- done: `bash tools/test_python.sh --suite stable`
resume: ---------------------------------------------------------------------- | Ran 3 tests in 0.020s | OK
resume: ---------------------------------------------------------------------- | Ran 3 tests in 0.035s | OK
- handoff lot_id: zeroclaw-integrations
owner_repo=Kill_LIFE
owner_agent=PM-Mesh
owner_team=PM
dependencies=none
rollback=Revenir à la lane `zeroclaw` manuelle si le container n8n échoue de manière persistante. | Rejouer `bash tools/run_autonomous_next_lots.sh run --no-write` puis arbitrer manuellement.
write_set=specs/zeroclaw_dual_hw_todo.md, tools/cockpit/lot_chain.sh, tools/cockpit/run_next_lots_autonomously.sh
## `mesh-governance` — Gouvernance mesh tri-repo
- done: lot detecte (Versionner le contrat tri-repo, verrouiller les ownerships agents, et outiller le preflight de synchro continue sans ecraser le travail des autres contributeurs.)
- done: `bash tools/cockpit/mesh_sync_preflight.sh --json`
resume: ] | } | WARN 2026-03-21 15:01:49 +0100 Mesh sync preflight degraded: downgrade to controlled lots for affected repos
- done: `bash tools/cockpit/ssh_healthcheck.sh --json`
resume: ] | } | INFO 2026-03-21 15:01:55 +0100 SSH health-check: all targets reachable
- done: `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/agent_handoff.schema.json --instance specs/contracts/examples/agent_handoff.mesh.json`
resume: "schema": "specs/contracts/agent_handoff.schema.json", | "instance": "specs/contracts/examples/agent_handoff.mesh.json" | }
- done: `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/repo_snapshot.schema.json --instance specs/contracts/examples/repo_snapshot.mesh.json`
resume: "schema": "specs/contracts/repo_snapshot.schema.json", | "instance": "specs/contracts/examples/repo_snapshot.mesh.json" | }
- done: `python3 tools/specs/mesh_contract_check.py --schema specs/contracts/workflow_handshake.schema.json --instance specs/contracts/examples/workflow_handshake.mesh.json`
resume: "schema": "specs/contracts/workflow_handshake.schema.json", | "instance": "specs/contracts/examples/workflow_handshake.mesh.json" | }
- handoff lot_id: mesh-governance
owner_repo=Kill_LIFE
owner_agent=PM-Mesh
owner_team=PM
dependencies=zeroclaw-integrations
rollback=Retirer le lot `mesh-governance` du déclenchement auto si la convergence reste bloquée. | Conserver le contrat mesh en mode lecture seule et documenter la dérogation.
write_set=docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md, docs/MACHINE_SYNC_STATUS_2026-03-20.md, docs/plans/19_todo_mesh_tri_repo.md, tools/cockpit/mesh_sync_preflight.sh, tools/cockpit/ssh_healthcheck.sh
## `mcp-runtime` — Alignement MCP runtime local
- done: lot detecte (Stabiliser les launchers MCP, le bootstrap Mac, la resolution du repo compagnon et la doc operateur associee.)
- done: `bash tools/bootstrap_mac_mcp.sh codex`
resume: codex mcp add openscad --env MASCARADE_DIR=/Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/mascarade-main -- bash /Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/run_openscad_mcp.sh | codex mcp add huggingface --url https://huggingface.co/mcp --bearer-token-env-var HUGGINGFACE_API_KEY | codex mcp add playwright -- npx -y @playwright/mcp@latest
- done: `bash tools/bootstrap_mac_mcp.sh json`
resume: } | } | }
- done: `.venv/bin/python tools/validate_specs_mcp_smoke.py --json --quick`
resume: {"status": "ready", "protocol_version": "2025-03-26", "server_name": "validate-specs", "tool_count": 2, "checks": ["initialize", "tools/list"], "error": null}
- advisory: `.venv/bin/python tools/knowledge_base_mcp_smoke.py --json --quick`
resume: {"status": "degraded", "protocol_version": "2025-03-26", "server_name": "knowledge-base", "provider": "memos", "tool_count": 4, "checks": ["initialize", "tools/list"], "secret_configured": false, "live_validation": "missing_secret", "error": "memos auth missing"}
- advisory: `.venv/bin/python tools/github_dispatch_mcp_smoke.py --json --quick`
resume: {"status": "degraded", "protocol_version": "2025-03-26", "server_name": "github-dispatch", "tool_count": 3, "checks": ["initialize", "tools/list"], "token_configured": false, "live_requested": false, "live_validation": "missing_secret", "error": "GitHub dispatch auth missing"}
- handoff lot_id: mcp-runtime
owner_repo=Kill_LIFE
owner_agent=Runtime-Companion
owner_team=Architect-Firmware
dependencies=zeroclaw-integrations
rollback=Désactiver les changements MCP introduits dans le lot et revenir à la configuration de référence. | Conserver la preuve de doc dans `docs/MCP_SETUP.md` et relancer uniquement en mode validation.
write_set=docs/MCP_SETUP.md, tools/bootstrap_mac_mcp.sh, tools/lib/runtime_home.sh, tools/run_github_dispatch_mcp.sh
## `cad-mcp-host` — Runtime CAD host-first
- done: lot detecte (Qualifier KiCad, FreeCAD et OpenSCAD en host-first sur macOS tout en gardant le fallback conteneur operable.)
- done: `bash tools/hw/run_kicad_mcp.sh --doctor`
resume: KICAD_PYTHON_STDERR_LOG_LEVEL=WARNING | REQUESTED_RUNTIME=auto | SELECTED_RUNTIME=container
- done: `bash tools/hw/cad_stack.sh doctor`
resume: PlatformIO Core, version 6.1.19 | [kill_life:cad] OK: CAD doctor checks executed successfully. | OpenSCAD version 2021.01
- done: `.venv/bin/python tools/freecad_mcp_smoke.py --quick --json`
resume: {"status": "ready", "protocol_version": "2025-03-26", "server_name": "freecad", "tool_count": 4, "checks": ["initialize", "tools/list", "get_runtime_info"], "error": null}
- done: `.venv/bin/python tools/openscad_mcp_smoke.py --quick --json`
resume: {"status": "ready", "protocol_version": "2025-03-26", "server_name": "openscad", "tool_count": 4, "checks": ["initialize", "tools/list", "get_runtime_info"], "error": null}
- handoff lot_id: cad-mcp-host
owner_repo=Kill_LIFE
owner_agent=Embedded-CAD
owner_team=Architect-Firmware
dependencies=mcp-runtime
rollback=Retour automatique au mode container-only (`tools/hw/cad_stack.sh`). | Conserver les chemins explicites de script pour éviter une dérive host-first.
write_set=docs/MCP_SETUP.md, tools/hw/cad_stack.sh, tools/hw/run_kicad_mcp.sh
## `yiacad-fusion` — Fusion KiCad + FreeCAD IA-native
- done: lot detecte (Mettre en place le lot YiACAD (`prepare`, `smoke`, `status`, `logs`, `clean-logs`) et la synthese operateur associee sans fusion automatique de `main`.)
- done: `bash tools/cad/yiacad_fusion_lot.sh --action prepare`
resume: - remotes: | - origin -> https://github.com/FreeCAD/FreeCAD.git | - upstream -> https://github.com/FreeCAD/FreeCAD.git
- done: `bash tools/cad/yiacad_fusion_lot.sh --action status`
resume: - origin -> https://github.com/FreeCAD/FreeCAD.git | - upstream -> https://github.com/FreeCAD/FreeCAD.git | Last log: /Users/electron/Documents/Lelectron_rare/Kill_LIFE/artifacts/cad-fusion/yiacad-fusion-last.log
- advisory: `bash tools/cad/yiacad_fusion_lot.sh --action smoke`
resume: - upstream -> https://github.com/FreeCAD/FreeCAD.git | ## smoke_failures | - KiCad MCP host smoke
- handoff lot_id: yiacad-fusion
owner_repo=Kill_LIFE
owner_agent=CAD-Fusion
owner_team=CAD-Fusion
dependencies=cad-mcp-host
rollback=Geler la branche `kill-life-ai-native` et revenir au mode container-only (`tools/hw/cad_stack.sh`). | Conserver les artefacts YiACAD (`artifacts/cad-fusion`) et la synthese hebdomadaire comme preuve. | Basculer l'execution en mode `status` + `clean-logs` si le smoke bloque.
write_set=docs/CAD_AI_NATIVE_FORK_STRATEGY.md, docs/OSS_AI_NATIVE_CAD_RESEARCH_2026-03-20.md, tools/cad/ai_native_forks.sh, tools/cad/yiacad_fusion_lot.sh, tools/cockpit/refonte_tui.sh, tools/cockpit/render_weekly_refonte_summary.sh
## `python-local` — Execution Python repo-locale
- done: lot detecte (Garder les scripts et smokes sur l'interpreteur repo-local plutot que sur le Python systeme.)
- done: `bash tools/test_python.sh --venv-dir .venv --suite stable`
resume: ---------------------------------------------------------------------- | Ran 3 tests in 0.075s | OK
- handoff lot_id: python-local
owner_repo=Kill_LIFE
owner_agent=Firmware
owner_team=Architect-Firmware
dependencies=mcp-runtime, cad-mcp-host
rollback=Revenir à l'exécution Python système si la venv locale est instable. | Limiter les changements au lot `tools/test_python.sh` jusqu'à stabilisation.
write_set=tools/test_python.sh, tools/run_validate_specs_mcp.sh, tools/validate_specs_mcp_smoke.py
docs/plans/19_todo_mesh_tri_repo.md
+260
View File
@@ -0,0 +1,260 @@
# TODO Mesh Tri-Repo 2026-03-20
## État de bord (2026-03-20 15:33)
- `mesh_status`: `degraded`
- Cause principale observée:
- Le preflight remonte en `degraded` pour `cils` sur les dépôts non-critiques (policy `cils-lockdown`) et pour `README.md` en `degraded`.
- `mesh_host_order` est conforme au profil `tower-first` : `clems@192.168.0.120 -> kxkm@kxkm-ai -> cils@100.126.225.111 -> local -> root@192.168.0.119`.
- La prochaine cause bloquante restante est la dérive de conformité docs/repo (specs/workflows count, via `readme_repo_coherence`).
- Source de preuve: `artifacts/cockpit/machine_alignment_daily_20260320_152957.json` + `artifacts/cockpit/health_reports/mesh_health_check_mesh_20260320_153202.json`.
- Priorité principale:
- stabiliser la conformité docs/repo (cohérence `specs/` et workflows) pour faire remonter le niveau `readme_status` à `ready`.
- maintenir la politique `cils-lockdown` (service non-essentiel uniquement).
- poursuivre `mesh_governance` dès résolution de la dérive `readme`.
- Source de vérité: `docs/TRI_REPO_MESH_CONTRACT_2026-03-20.md` + `docs/REFACTOR_MANIFEST_2026-03-20.md`.
## P0
- [x] Formaliser le contrat mesh tri-repo versionne.
- [x] Ajouter un preflight TUI de convergence multi-machines/multi-repos.
- [x] Formaliser les statuts `ready | degraded | blocked` pour les surfaces MCP.
- [x] Mettre a jour la gouvernance agents/sous-agents pour un mode multi-contributeurs.
- [x] Propager le contrat mesh dans `mascarade` (`T-MESH-005`).
- Lot attendu: `T-MESH-005`
- Propriétaire: `PM-Mesh` + `Arch-Mesh`
- [x] Propager le handshake workflow dans `crazy_life` (`T-MESH-006`).
- Lot attendu: `T-MESH-006`
- Propriétaire: `PM-Mesh` + `Runtime`
- [x] Valider la lane opérateur `dry-run` et `live` sur `clems`.
- Lot attendu: `T-OL-001`
- Propriétaire: `Runtime-Companion` + `SyncOps`
- [x] Uniformiser les artefacts lot-tracking (`specs/03_plan.md` + `specs/04_tasks.md`) avec ce contrat.
- Lot attendu: `T-MESH-007`
- Commandes canoniques:
- `bash tools/run_autonomous_next_lots.sh status`
- `bash tools/cockpit/lot_chain.sh plan --yes`
- Dépendance: `T-RE-302`
- [x] Propager le patchset `post-E2E hardening` sur les lanes mesh et rétablir la visibilité preflight sur `clems`.
- Lot attendu: `T-OL-002`
- Propriétaire: `SyncOps`
## P1
- [x] Ajouter une TUI d'analyse/purge de logs avec sortie JSON.
- [x] Rafraichir la veille OSS officielle et la relier a la gouvernance mesh.
- [x] Faire consommer le contrat de handoff par tous les lots `autonomous_next_lots` validés en mode `autonomous next lots`.
- [x] Ajouter une validation CI du workflow schema handshake (`T-CI-001`).
- Lot attendu: `T-CI-001`
- [x] Uniformiser les handoff de lot (`lot_id`, `owner_repo`, `owner_agent`, `write_set`) dans les logs d’exécution.
- Lot attendu: `T-LC-007`
- Réalisé par la génération JSON de `tools/autonomous_next_lots.py` (`lot_id`, `owner_repo`, `owner_agent`, `write_set`).
- [x] Ajouter le load balancing P2P dynamique du preflight mesh, avec cils verrouillé (`Kill_LIFE` prioritaire) et arbitrage par load_ratio.
- Lot attendu: `T-LB-001`
- Réalisé par: `tools/cockpit/mesh_sync_preflight.sh --load-profile`
- [x] Formaliser la stratégie de garde CILS dans le contrat opérationnel (load profile + photo-safe + non-essentiel).
- Lot attendu: `T-LB-005`
- Réalisé par: `docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md`, `tools/cockpit/ssh_healthcheck.sh`, `docs/plans/12_plan_gestion_des_agents.md`
- [x] Durcir le parsing du payload distant pour éviter les sorties SSH non-conformes et garantir un JSON stable.
- Lot attendu: `T-LB-002`
- Réalisé par: `tools/cockpit/mesh_sync_preflight.sh` (`snapshot_repo_remote`)
- [x] Ajouter une passe de rapprochement des métriques d’exécution `ready/degraded/blocked` entre `mesh_sync_preflight`, `readme_repo_coherence`, `log_ops`.
- Lot attendu: `T-RE-208`
- Réalisé par: `tools/cockpit/mesh_health_check.sh`
- [x] Documenter le contrat runtime provider réellement observé sur la lane opérateur.
- Lot attendu: `T-OL-003`
- Réalisé par: `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`
- [x] Exposer l’ordre de scheduling P2P dans la sortie JSON du preflight (`host_order`) pour rendre la décision Tower-first/photon-safe transparente.
- Lot attendu: `T-LB-004`
- Réalisé par: `tools/cockpit/mesh_sync_preflight.sh`
- [x] Ajouter un outil TUI dédié à la propagation du patchset opérateur.
- Lot attendu: `T-OL-004`
- Réalisé par: `tools/cockpit/full_operator_lane_sync.sh`
- [x] Bloquer strictement tout précheck CILS en mode `photon-safe` (hors SSH) pour éviter toute surcharge de `photon`.
- Lot attendu: `T-LB-003`
- Réalisé par: `tools/cockpit/mesh_sync_preflight.sh` (règle `photon-safe`)
## P2
- [x] Weekly summary automatique par agent principal.
- Lot attendu: `T-RE-301`
- Réalisé par: `tools/cockpit/render_weekly_refonte_summary.sh`
- [ ] Evidence packs consolides multi-repos.
- [ ] Assistant operator pour pilotage de lots controles.
- [x] Checklist de sortie lot avec preuves log + mesh + preflight.
- Lot attendu: `T-RE-304`
- Réalisé par: `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md` + `artifacts/cockpit/weekly_refonte_summary.md`
- [x] Outil de suivi "runbook mesh" pour lancer `mesh + lots + logs` dans un ordre canonique.
- Lot attendu: `T-MESH-010`
- [x] Reporter la matrice d'owners dans les TODOs companions sans toucher aux hotspots `single-writer`.
- Lot attendu: `T-AG-102`
- Réalisé par:
- `mascarade-main/docs/TODO_MESH_TRI_REPO_2026-03-20.md`
- `crazy_life-main/docs/TODO_MESH_TRI_REPO_2026-03-20.md`
## Agents dédiés à la passe Mesh (2026-03-20)
- `PM-Mesh` (PM-Plan, Risk-Triager): priorisation + résolution `mascarade` branch/clone.
- `Arch-Mesh` (Schema-Guard, Compat-Auditor): revue handshake + compatibilité schema.
- `QA-Compliance` (Spec-Mirror, Evidence-Pack): contrôle evidence + CI contracts.
- `SyncOps` (SSH-Health, Log-Ops): health-check, purge logs, relance contrôlée.
## Matrice de compétences et tâches
| Agent | Compétences | Tâches ouvertes |
| --- | --- | --- |
| PM-Mesh | triage lot, coordination multi-repo, priorisation | `T-MESH-005`, `T-MESH-006`, réconciliation topologie |
| Arch-Mesh | validation schema, compatibilité contractuelle | CI schema handshake, preuve de migration |
| Embedded-CAD | CAD/MCP, fork AI-native | branche `kill-life-ai-native`, préflight host-first |
| Runtime-Companion | providers, logs, providers health | statut MCP runtime + smoke |
| QA-Compliance | tests, trace, evidence packs | validation tickets lot + état `blocked/degraded/ready` |
| Docs-Research | doc delta, Mermaid, veille officielle | `T-OL-003`, README/index/full-operator delta |
## Sous-tâches lot-level ouvertes
- `zeroclaw-integrations` : propriétaire `PM-Mesh`, sous-agent `Runtime-Smoke`, preuve attendue `T-RE-204`.
- `mesh-governance` : propriétaire `Arch-Mesh`, sous-agent `Schema-Guard`, focus `T-MESH-007`.
- `post-e2e-hardening` : propriétaire `Runtime-Companion`, sous-agents `Compat-Guard` + `SyncOps`, focus `T-OL-002`, `T-OL-003`, `T-OL-004`.
- `yiacad-fusion` : propriétaire `Arch-Mesh`, sous-agents `CAD-Bridge` + `CAD-Smoke`, focus `T-RE-209` et `T-RE-210`.
- `weekly-summary` : propriétaire `SyncOps`, sous-agent `Doc-Runbook`, focus `T-RE-301`.
## Actions de convergence ouvertes après preflight
- [ ] Restaurer le snapshot exploitable de `mascarade-main` sur `clems@192.168.0.120`.
- [ ] Relancer `mesh_sync_preflight --load-profile tower-first --json` sur la fenêtre `clems` et confirmer `mesh_status=ready`.
- [x] Restaurer le snapshot exploitable de `mascarade-main` sur `clems@192.168.0.120`.
- [x] Vérifier `load_profile: tower-first` dans `host_order` (`clems -> kxkm -> cils -> local -> root`) après correction parser.
- [x] Propager le patchset `post-E2E hardening` via `bash tools/cockpit/full_operator_lane_sync.sh --json`.
- [ ] Lancer `mesh_health_check --load-profile tower-first --json` et consigner `mesh_host_order` dans le lot-log.
- [x] Purger les `._*` apparus sur les lanes companions lorsque la passe de sync sera stabilisée.
- [ ] Harmoniser les lots ouverts (12/18/19 + specs/03/04) via `bash tools/cockpit/lot_chain.sh plan --yes`.
- [x] Relancer `mesh_sync_preflight --load-profile tower-first` pour valider le parsing robuste.
## Delta 2026-03-20 15:45 - owner matrix + dirty-set cleanup
- [x] `T-AG-102` execute: overlay d'owners reporte dans les TODOs companions `mascarade-main` et `crazy_life-main`.
- [x] Dirty-sets mesh inter-machines realignes:
- `Kill_LIFE-main = 27`
- `mascarade-main = 6`
- `crazy_life-main = 6`
- aligne sur `local`, `clems`, `kxkm`, `root`, `cils`
- [x] Purge des artefacts Apple `._*` et `.DS_Store` effectuee sur les lanes mesh.
- [ ] `mesh_status=ready` reste bloque par la policy `cils-lockdown` et par la convergence des checks de conformite docs/repo, non par un ecart Git reel.
## Delta 2026-03-20 15:55 - regeneration trackers 18*
- [x] `bash tools/run_autonomous_next_lots.sh status` relance pour regenérer les trackers `18_plan` et `18_todo`.
- [x] Le lot suivant est formalise en `T-MESH-007`.
- [x] La commande canonique de synchronisation des plans/todos devient `bash tools/cockpit/lot_chain.sh plan --yes`.
- [x] `bash tools/cockpit/lot_chain.sh plan --yes` execute pour resynchroniser les blocs auto `specs/03_plan.md` et `specs/04_tasks.md`.
## Delta 2026-03-20 14:15 - alignement runbook + tolérance dégradée
- [x] Mise à jour des plans 18* pour intégrer la boucle lot -> incident register -> status sync.
- [x] Hardening préflight mesh: sortie SSH invalide now mapped to state `degraded/unreachable`, sans crash.
- [x] Charge policy et ordonnancement `tower-first/photon-safe` stabilisés pour la passe quotidienne.
## Resolus le 2026-03-20
- [x] Fournir un clone mesh `mascarade-main` exploitable sur `kxkm@kxkm-ai` sans ecraser `/home/kxkm/mascarade`.
- [x] Fournir un clone mesh `mascarade-main` sur `root@192.168.0.119` sans toucher la lane `feat/apple-coreml-runtime-lot` de `/root/mascarade-github`.
- [x] Aligner les miroirs mesh `mascarade-main` sur le SHA `d8bca38d384e47ca17e336b49a11164c579ad3c6`.
## Resolus le 2026-03-20 apres normalisation Kill_LIFE
- [x] Fournir un clone mesh `Kill_LIFE-main` sur local, `clems`, `root` et `kxkm-ai`.
- [x] Aligner les miroirs mesh `Kill_LIFE-main` sur le SHA `bd3f7b99154f86057ba18b9948d940df55722b12`.
- [x] Faire remonter `mesh_status=ready` sur le preflight tri-repo.
## Resolus le 2026-03-20 apres propagation compagnons
- [x] Localiser le contrat mesh runtime dans `mascarade`.
- [x] Localiser le contrat mesh web dans `crazy_life`.
- [x] Reserver des lanes `crazy_life-main` dediees pour la sync controlee.
## Resolus le 2026-03-20 apres propagation machine companion
- [x] Propager le contrat mesh runtime dans `mascarade-main` sur local, `clems`, `root`, `kxkm-ai`.
- [x] Propager le contrat mesh web dans `crazy_life-main` sur local, `clems`, `root`, `kxkm-ai`.
- [x] Etendre le preflight tri-repo aux lanes `crazy_life-main`.
- [x] Faire remonter `mesh_status=ready` apres propagation des trois repos sur les miroirs dedies.
## Resolus le 2026-03-20 apres ajout de `cils`
- [x] Integrer `cils@100.126.225.111` comme cible SSH operateur supplementaire.
- [x] Sauvegarder la lane partielle `Kill_LIFE-main` issue du premier clone rate sans l'ecraser.
- [x] Fournir des miroirs mesh `Kill_LIFE-main`, `mascarade-main`, `crazy_life-main` sur `/Users/cils`.
- [x] Etendre le health-check SSH a `cils`.
- [x] Corriger le preflight tri-repo pour shells distants `zsh` en forcant le snapshot via `bash -s`.
- [x] Faire remonter `mesh_status=ready` sur `clems`, `root`, `kxkm-ai` et `cils`.
## Resolus le 2026-03-20 apres propagation companion + lot schemas
- [x] Ajouter un preflight mesh local a `mascarade-main`.
- [x] Ajouter un preflight mesh local a `crazy_life-main`.
- [x] Etendre les contrats compagnons et leurs README a `cils@100.126.225.111`.
- [x] Publier les schemas machine-readables `agent_handoff`, `repo_snapshot`, `workflow_handshake`.
- [x] Ajouter un checker local sans dependance externe pour les contrats mesh.
## Resolus le 2026-03-20 apres branchement du checker
- [x] Faire consommer `mesh_contract_check.py` par `tools/autonomous_next_lots.py`.
- [x] Faire consommer les schemas mesh par les preflights compagnons `mascarade-main` et `crazy_life-main`.
- [x] Ajouter un workflow CI visible pour les exemples `agent_handoff`, `repo_snapshot`, `workflow_handshake`.
- [x] Executer explicitement le lot `mesh-governance` avec succes sur les 5 validations requises.
## Delta 2026-03-20 14:00 - full operator lane
- [x] Added the `embedded-operator-live` workflow as the stable operator E2E source of truth.
- [x] Added the live-provider evidence contract and example payload.
- [x] Added the TUI runbook `tools/cockpit/full_operator_lane.sh`.
- [x] Added the `operator.live-provider` action in `crazy_life`.
- [x] Aligned companion docs on the live-provider bridge.
## Delta 2026-03-20 14:45 - post-E2E hardening
- [x] Dry-run validated on `clems` with `run_id=4a9adf87-1695-4321-86a2-e066a0988533`.
- [x] Live validated on `clems` with `run_id=5ef4909f-8747-4634-a6a6-d131692787b0`.
- [x] The live bridge is now container-safe through `operator_live_provider_smoke.js`.
- [x] The runtime payload now uses a top-level `system` field instead of a `system` message role.
- [x] Official compatibility note captured in `docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md`.
- [ ] Mesh preflight still needs a conservative recovery pass on `clems` before the lane can return to `ready`.
## Delta 2026-03-20 14:58 - staged sync + preflight
- [x] `bash tools/cockpit/full_operator_lane_sync.sh --json` executed successfully in `staged` mode on the 4 mesh targets.
- [x] `mesh_sync_preflight --json` moved from `blocked` back to `degraded`.
- [x] `Kill_LIFE-main` and `crazy_life-main` are visible again on `clems`.
- [ ] `mascarade-main` on `clems` still needs a conservative repair pass before the mesh can return to `ready`.
## Delta 2026-03-20 16:21 - registre machine branche + YiACAD clarifie
- [x] `T-RE-214` cloture:
- `ssh_healthcheck.sh` charge maintenant les cibles SSH depuis `specs/contracts/machine_registry.mesh.json`
- `run_alignment_daily.sh` embarque maintenant un resume JSON du registre dans ses artefacts
- preuves:
- `bash tools/cockpit/ssh_healthcheck.sh --json`
- `bash tools/cockpit/run_alignment_daily.sh --json --skip-mesh --skip-log-ops --no-purge`
- [x] Le lot mesh consomme desormais une source unique de roles/ports/priorites sur ses runbooks centraux.
- [ ] `yiacad-fusion` reste bloque, mais la cause est maintenant explicite et stable:
- `mascarade-main/finetune/kicad_mcp_server` est present comme sous-module non materialise
- l'entrypoint attendu `dist/index.js` manque, donc `KiCad MCP host smoke` reste `blocked`
- le mode `auto` retombe maintenant proprement vers `container`
- [ ] Prochaine action mesh utile:
- rerun `mesh_health_check --json --load-profile tower-first` avec le resume registre embarque
- reporter l'etat degrade courant sans confondre `yiacad-fusion` bloque et `mesh` documentaire/runbook
## Delta 2026-03-20 16:54 - T-OL-002 restaure sur clems
- [x] `bash tools/cockpit/full_operator_lane_sync.sh --json` relance en mode `staged`: `status=done`, `targets=4`
- [x] `mesh_sync_preflight --json --load-profile tower-first` rerun apres hardening parser:
- `clems/mascarade-main`: `ready`
- `clems/crazy_life-main`: `ready`
- [x] `T-OL-002` peut etre considere comme ferme cote visibilite preflight sur `clems`
- [ ] `mesh_status` reste `degraded`, mais pour des motifs distincts du lot operateur:
- `cils-lockdown` non critique sur `mascarade` et `crazy_life`
- dirty counts encore divergents entre certaines lanes
- probe de charge `clems` encore marque `degraded:invalid-load-output`
- 2026-03-20 17:05 +0100 - T-RE-401 done: job GitHub visible ajoute via `.github/workflows/docs_reference_gate.yml`; audit local `bash tools/doc/readme_repo_coherence.sh audit` vert.
docs/plans/20_plan_refonte_ui_ux_yiacad_apple_native.md
+281
View File
@@ -0,0 +1,281 @@
# 20) Plan de refonte UI/UX YiACAD Apple-native
Last updated: 2026-03-21 CET
## Mission
Transformer `YiACAD` en shell CAD IA-native cohérent, lisible et orienté tâches, aligné sur les recommandations Apple officielles disponibles au `2026-03-20`.
## Lots
| Lot | Priorité | Objectif | Sortie attendue |
| --- | --- | --- | --- |
| `T-UX-001` | P0 | audit, recherche et feature map Apple-native | audit, research, feature map, spec |
| `T-UX-002` | P0 | owners, sous-agents et surfaces initiales YiACAD | matrice agents + docs de cadrage |
| `T-UX-003` | P1 | montée native progressive vers les points d’insertion KiCad/FreeCAD documentés | hooks natifs shell/workbench/control |
| `T-UX-004` | P1 | contract `command palette + inspector persistant` dans les surfaces déjà YiACAD | palette légère + inspector/review center alignés |
| `T-UX-005` | P2 | review center consolidé multi-surface | regroupement `ERC/DRC/BOM/sync` |
| `T-UX-006` | P2 | inspector IA contextuel + taxonomie stable | détail, provenance, suggestions |
| `T-UX-007` | P2 | intégration shell compilée profonde | `MainWindow`, `DockWindowManager`, `webview_panel` |
| `T-UX-008` | P3 | App Intents / automatisations locales | trajectoire macOS systemwide |
Note de normalisation:
- la TUI UI/UX reste un runbook support déjà livré;
- elle n’utilise plus l’identifiant canonique `T-UX-003`, réservé aux points d’insertion natifs.
## Agents affectés
| Lead | Sous-agents | Responsabilité |
| --- | --- | --- |
| `UX-Lead` | `Apple-HIG`, `UI-Research` | vision Apple-native, veille officielle, arbitrage UX |
| `CAD-UX` | `KiCad-Surface`, `FreeCAD-Surface` | convergence des surfaces CAD |
| `TUI-Ops` | `Log-Guard`, `Runbook-Doc` | script TUI, logs, purge, runbook |
| `Doc-Research` | `Mermaid-Map`, `README-Align` | docs, diagrammes, feature map, README |
## Affectation de tranche active
| Sous-lot | Owner | Sous-agent | Write-set de tranche |
| --- | --- | --- | --- |
| `T-UX-003A` | `CAD-UX` | `KiCad-Shell` | `.runtime-home/cad-ai-native-forks/kicad-ki/pcbnew/toolbars_pcb_editor.cpp`, `.runtime-home/cad-ai-native-forks/kicad-ki/eeschema/toolbars_sch_editor.cpp` |
| `T-UX-003B` | `CAD-UX` | `FreeCAD-Shell` | `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py` |
| `T-UX-003C` | `CAD-UX` | `KiCad-Native` | `.runtime-home/cad-ai-native-forks/kicad-ki/pcbnew/tools/board_editor_control.*`, `.runtime-home/cad-ai-native-forks/kicad-ki/eeschema/tools/sch_editor_control.*` |
| `T-UX-003D` | `CAD-UX` | `FreeCAD-Native` | `.runtime-home/cad-ai-native-forks/freecad-ki/src/Gui/MainWindow.cpp` |
| `T-UX-004A` | `CAD-UX` | `KiCad-Surface`, `FreeCAD-Surface` | `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin/yiacad_action.py`, `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py` |
| `T-UX-004B` | `Doc-Research` | `Mermaid-Map`, `OSS-Watch` | `docs/YIACAD_*`, `specs/04_tasks.md`, `docs/plans/20_*` |
| `Support UI/UX Ops` | `SyncOps` | `TUI-Ops`, `Log-Guard` | `tools/cockpit/yiacad_uiux_tui.sh`, `artifacts/uiux_tui/*` |
## Plan d’exécution
```mermaid
flowchart TD
Audit["Audit complet"] --> Research["Recherche Apple + OSS"]
Research --> Spec["Spec UI/UX"]
Spec --> Shell["Shell review/sync/inspect"]
Shell --> TUI["TUI UI/UX"]
Shell --> Native["Hooks directs dans les forks"]
Native --> ReviewCenter["Review center"]
Native --> Inspector["Inspector IA"]
ReviewCenter --> Metrics["Mesures et adoption"]
Inspector --> Metrics
```
## Critères d’acceptation
- accès direct à `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`, `Status`, `Artifacts`;
- hiérarchie claire des actions primaires et secondaires;
- documentation reliée depuis le README;
- plan, TODO et agent management synchronisés;
- artefacts et logs toujours disponibles pour audit.
## Delta 2026-03-20 16:35 - lot actif
- lot actif: `T-UX-003`
- sous-agents actifs:
- `KiCad-Native`
- `FreeCAD-Native`
- `Doc-Entry`
- objectif de passe: première montée native compilée minimale, sans casser les surfaces Python déjà installées
## Delta 2026-03-20 17:18 - normalisation T-UX
- `T-UX-003` est le canon pour la montée native KiCad/FreeCAD vers les shells documentés.
- `T-UX-004` ouvre d'abord un lot sûr dans les surfaces déjà contrôlées par YiACAD, avant les hotspots compilés `MainWindow`, `DockWindowManager` et `webview_panel`.
- la TUI UI/UX reste un support ops/résilience, découplé de la numérotation produit.
## Delta 2026-03-20 17:18 - lot sûr T-UX-004
- FreeCAD reçoit une palette légère dans le dock `YiACAD Inspector`, avec déclenchement direct des actions natives.
- KiCad reçoit une première `command palette` légère dans le plugin YiACAD natif, sans toucher aux fichiers cœur compilés.
- le `review center` reste un regroupement léger à cette étape; la consolidation profonde reste portée par `T-UX-005`.
## Delta 2026-03-20 18:12 - T-UX-003 shell hooks
- agents dédiés actifs:
- `CAD-UX / KiCad-Shell`: shell toolbars `pcbnew` + `eeschema`
- `CAD-UX / FreeCAD-Shell`: prochaine passe `MainWindow` / `DockWindowManager`
- `Doc-Research / OSS-Watch`: veille officielle KiCad / FreeCAD
- incrément livré:
- regroupement des actions YiACAD dans un groupe shell `YiACAD Review` côté `pcbnew` et `eeschema`
- aucune ouverture de write-set sur `eda_base_frame.cpp`, `MainWindow.cpp` ou `DockWindowManager.cpp` à cette passe
- décision:
- conserver ce lot comme montée shell progressive et garder les hotspots compilés pour une tranche dédiée
- figer `EDA_BASE_FRAME` en `no-touch` pour `T-UX-003`
- toute extension shell KiCad doit rester symétrique entre `pcbnew` et `eeschema` tant que le runner reste dupliqué et synchrone
- garder FreeCAD côté workbench `yiacad_freecad_gui.py` tant que le shell global n’a pas une tranche dédiée; si on monte plus bas, `MainWindow.cpp` est la seule cible admissible au prochain pas
## Delta 2026-03-20 16:55 - résultat de passe
- KiCad: premier point d’entrée natif livré dans `kicad_manager` (`YiACAD Status`).
- FreeCAD: premier inspector dockable livré dans `YiACADWorkbench`.
- Documentation opératoire: points d’entrée et handoffs design raccordés.
- Suivant: étendre `T-UX-003` à `pcbnew` / `eeschema`, puis ouvrir `T-UX-004`.
## Delta 2026-03-20 - T-UX-003 native shells
- Le lot `T-UX-003` atteint maintenant trois surfaces KiCad compilées: `KiCad Manager`, `pcbnew`, `eeschema`.
- La stratégie retenue reste progressive: insertion native dans le shell existant, réutilisation transitoire du bridge `yiacad_ai_bridge.py`, puis remplacement par des hooks backend YiACAD directs.
- FreeCAD dispose déjà du `YiACAD Inspector` dockable côté workbench; la prochaine étape native profonde reste l'ancrage hors simple surface Python.
- Le lot suivant recommandé reste `T-UX-004` pour la `command palette`, l'inspector persistant et la revue contextualisée multi-surface.
## Delta 2026-03-20 - direct hooks over native ops
- Le bridge local `yiacad_ai_bridge.py` n'est plus le chemin cible des surfaces natives principales.
- `KiCad Manager`, `pcbnew`, `eeschema` et le workbench FreeCAD branchent désormais directement `yiacad_native_ops.py`.
- Les quatre actions natives de base sont stabilisées au niveau UI: `Status`, `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`.
- Le prochain approfondissement UX doit maintenant porter sur l'orchestration, la persistance et la lisibilité des retours, pas seulement sur le câblage des commandes.
## Delta 2026-03-20 - pivot vers orchestration UX
- L'audit exhaustif est maintenant formalise dans `docs/YIACAD_EXHAUSTIVE_REFOUNTE_AUDIT_2026-03-20.md`.
- Le lot suivant cible explicitement l'orchestration: palette de commandes, review center, inspector persistant, contrats de sortie communs.
- La priorite se deplace du simple `wiring` vers la restitution des resultats, la persistance du contexte et la reduction de la charge cognitive.
## Delta 2026-03-20 18:35 - enchainement plans/todos
- `T-UX-003` est decoupe en sous-lots `A -> D` pour eviter les write-sets croises entre KiCad, FreeCAD workbench et FreeCAD shell global.
- `T-UX-004` est decoupe en sous-lots `A -> B`, avec un lot produit (`palette/inspector`) et un lot doc/contrat (`sortie UX commune`).
- `Support UI/UX Ops` devient une lane explicite, hors numerotation produit, pour piloter plans, preuves, logs et runbook TUI.
## Delta 2026-03-20 18:52 - T-UX-003C helper symmetry
- `T-UX-003C` avance sur le plus petit write-set natif sûr: `pcbnew/tools/board_editor_control.cpp` et `eeschema/tools/sch_editor_control.cpp`.
- Les deux control-layers resolvent maintenant l’interpreteur Python YiACAD via la meme chaine de fallback: settings KiCad, `PYTHON_EXECUTABLE`, puis `python3`.
- `ShowYiacadStatus` passe desormais par le helper canonique des deux cotes, ce qui reduit le drift avant toute insertion native plus profonde.
## Delta 2026-03-20 22:49 - T-UX-004B output contract
- `T-UX-004B` est ferme comme lot doc/contrat.
- Le contrat de sortie UX commun YiACAD est publie avec une doc lisible, un schema JSON et un exemple machine-readable.
- La TUI YiACAD expose maintenant ce contrat dans `proofs`, pour garder la lane auditable sans lecture implicite des specs.
## Consolidation canonique 2026-03-20
- `T-UX-003`:
- essentiellement livre sur `KiCad Manager`, `pcbnew`, `eeschema`
- FreeCAD est stable au niveau `YiACADWorkbench`, avec un reste d'ancrage shell plus profond hors de ce palier
- le chemin principal appelle maintenant `yiacad_native_ops.py`
- `T-UX-004`:
- ouvert et structure
- `T-UX-004B` ferme
- reste a executer: palette unifiee, `review center`, inspector persistant et lecture du contexte projet
- Priorite UI/UX immediate:
- reduire la charge cognitive
- rendre les resultats lisibles sans lecture manuelle des artefacts
- garder un fallback non-IA clair et auditable
- Dependance architecture immediate:
- `T-UX-004` doit maintenant consommer le backend local YiACAD (`context.json` + `uiux_output.json`) plutot qu'un simple retour texte de CLI
## Delta 2026-03-20 23:06 - T-UX-003D shell anchor
- `T-UX-003D` avance via `freecad-ki/src/Gui/MainWindow.cpp` seul.
- Un dock shell compile `Std_YiACADShellView` est cree dans `MainWindow`, cache par defaut et reserve comme ancrage stable pour la convergence future du shell YiACAD.
- `DockWindowManager.cpp` et `ComboView.cpp` restent hors write-set; le workbench Python conserve l’autorite produit tant que le contrat shell profond n’est pas complet.
## Delta 2026-03-20 23:22 - T-UX-003D shell card scaffold
- Le dock `Std_YiACADShellView` expose maintenant les rubriques du contrat de sortie YiACAD (`surface`, `status`, `severity`, `summary`, `artifacts`, `next_steps`).
- Le shell FreeCAD dispose donc d’une première lecture produit du contrat, sans dépendre encore d’un backend temps réel ni d’un dock manager custom.
- `T-UX-003D` est considéré comme atteint pour la phase de préparation shell via `MainWindow.cpp` seul.
## Delta 2026-03-21 - T-UX-004A + operator index
- `T-UX-004A` est effectivement livre sur les surfaces deja controlees par YiACAD.
- KiCad plugin et FreeCAD workbench consomment maintenant le contrat backend JSON pour la palette legere et le review center leger.
- l'entree operateur cross-lanes devient `yiacad_operator_index.sh`, tandis que `yiacad_uiux_tui.sh` reste la lane produit.
## Delta 2026-03-21 - T-UX-005 delivered
- le review center est maintenant enrichi sur KiCad plugin et FreeCAD workbench.
- la presentation est structuree par sections et met mieux en avant le contexte projet, les artefacts et les prochaines actions.
- le prochain focus UX devient la persistance de l'inspector et de la session de revue.
## Delta 2026-03-21 - preuve backend UI/UX
- la lane UI/UX dispose maintenant d'une preuve operateur canonique via:
- `bash tools/cockpit/yiacad_backend_proof.sh --action run`
- cette preuve complete la TUI UI/UX sans ouvrir de GUI:
- KiCad helper -> facade backend -> `uiux_output`
- FreeCAD helper -> facade backend -> `uiux_output`
- le prochain front UX ne porte plus sur le simple transport, mais sur la persistance de l'inspector et de la session de revue.
## Delta 2026-03-21 - T-UX-006A session persistante
- premiere tranche produit de `T-UX-006` executee sur le plus petit write-set Python utile:
- plugin KiCad: restauration et persistance de la derniere session de revue
- workbench FreeCAD: persistance/rechargement de la meme session de revue
- la session canonique est maintenant lisible sans GUI via:
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-session`
- les docks compiles profonds restent hors write-set a cette passe.
## Delta 2026-03-21 - T-UX-006B historique et taxonomie
- deuxieme tranche produit de `T-UX-006` executee sans ouvrir les hotspots compiles:
- l'historique de revue est maintenant persiste dans `artifacts/cad-ai-native/review_history.json`
- une taxonomie legere classe les actions en `review`, `analysis`, `sync`, `status`, `artifacts`
- l'historique est lisible via `yiacad_uiux_tui.sh` et `yiacad_operator_index.sh`
- le prochain front UX devient l'enrichissement visuel/contextuel de l'inspector, pas la simple retention des payloads.
## Delta 2026-03-21 - T-UX-006C vue operateur
- une vue operateur lisible de la taxonomie de revue est maintenant disponible:
- `bash tools/cockpit/yiacad_uiux_tui.sh --action review-taxonomy`
- `bash tools/cockpit/yiacad_operator_index.sh --action review-taxonomy`
- cette tranche ferme le passage de l'historique brut a une lecture exploitable par l'operateur.
## Delta 2026-03-21 - T-UX-006 delivered
- KiCad plugin:
- bandeau de session persistant
- reprise du dernier contexte et du dernier contrat
- FreeCAD workbench:
- en-tete de session persistant
- trajet recent et continuite visuelle entre actions
- le prochain focus UX ne porte plus sur la persistance de base, mais sur une session de revue plus riche et plus durable.
## Delta 2026-03-21 - T-ARCH-101C impact UI/UX
- les surfaces Python YiACAD actives passent maintenant par un client backend `service-first`.
- le fallback direct reste conserve pour ne pas casser les surfaces deja livrées.
- cette base permet de faire evoluer l'UX sans continuer a empiler de la logique d'appel direct dans chaque surface.
## Delta 2026-03-21 - T-UX-006D contexte compact
- une tranche compacte de la session riche est maintenant livree sans ouvrir les hotspots compiles:
- KiCad expose un contexte de revue recent enrichi de taxonomie et des dernieres actions
- FreeCAD affiche un trail enrichi avec synthese de taxonomie
- la TUI et l'index operateur exposent `review-context` comme vue courte consolidee
- le prochain front UX ne porte plus sur la visibilite brute de l'historique, mais sur l'eventuel enrichissement multi-vues ou la propagation vers les shells compiles quand le write-set sera acceptable.
## Delta 2026-03-21 - T-UX-006E contexte de preuve utile
- le builder de contexte YiACAD calcule maintenant un `context_ref` deterministe a partir du chemin demande, meme si la preuve utilise encore un fichier absent.
- la vue `review-context` reste donc metierement honnete (`blocked`) mais n'affiche plus un contexte vide en tete.
- cette tranche referme le residuel operateur le plus visible sans ouvrir le blocage runtime externe `yiacad-fusion`.
## Delta 2026-03-21 - T-UX-006F fixtures de preuve stables
- la preuve backend YiACAD bascule sur des fixtures suivies dans le repo pour fiabiliser le contexte recent.
- le prochain front UX ne porte donc plus sur des chemins temporaires ou ambigus, mais sur un contexte de preuve reproductible et versionne.
## Delta 2026-03-21 - T-UX-006D contexte de revue
- une nouvelle tranche produit dérivée de `T-UX-006` expose un contexte de revue synthétique dans les surfaces YiACAD déjà contrôlées:
- session courante
- taxonomie récente
- trail récent
- prochaines étapes dédupliquées
- write-set ciblé:
- `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin/yiacad_action.py`
- `.runtime-home/cad-ai-native-forks/freecad-ki/src/Mod/YiACADWorkbench/yiacad_freecad_gui.py`
- `tools/cockpit/yiacad_uiux_tui.sh`
- `tools/cockpit/yiacad_operator_index.sh`
## 2026-03-21 - Lot update
- `T-ARCH-101C` etendu: les surfaces KiCad compilees passent en `service-first` via `tools/cad/yiacad_backend_client.py`, avec auto-start du service local et fallback direct vers `tools/cad/yiacad_native_ops.py`.
- `T-OPS-119` consolide: `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable avec `status`, `uiux`, `global`, `backend`, `proofs` et des alias de compatibilite conserves.
- Risque residuel: aucune validation d'execution n'a ete lancee; l'extension aux call sites compiles restants doit etre traitee dans un lot separe.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
## Delta 2026-03-21 - closure T-UX-003 / T-UX-004
- `T-UX-003` est ferme comme lot parent:
- `kicad_manager`, `pcbnew`, `eeschema` et `YiACADWorkbench` portent les surfaces natives utiles
- `MainWindow.cpp` expose l'ancrage shell compile `Std_YiACADShellView`
- `test/test_yiacad_native_surface_contract.py` verrouille ce contrat de presence
- `T-UX-004` est ferme comme lot parent:
- plugin KiCad et workbench FreeCAD exposent `Command Palette`, `Review Center`, session persistante et contexte recent
- la surface produit canonique reste volontairement Python-first tant que les hotspots shell profonds ne sont pas priorises
- les suites profondes se deplacent vers `T-UX-007`; elles ne rouvrent plus `T-UX-003` ni `T-UX-004`.
docs/plans/20_todo_refonte_ui_ux_yiacad_apple_native.md
+207
View File
@@ -0,0 +1,207 @@
# 20) TODO - Refonte UI/UX YiACAD Apple-native
Last updated: 2026-03-21 CET
## P0
- [x] `T-UX-001` Publier l’audit UI/UX Apple-native.
- [x] `T-UX-001` Publier la recherche Apple + OSS.
- [x] `T-UX-001` Publier la feature map dédiée.
- [x] `T-UX-002` Poser la spec UI/UX Apple-native.
- [x] `T-UX-002` Installer les surfaces utilisateur KiCad/FreeCAD.
- [x] `T-UX-002` Brancher les surfaces sur `ERC/DRC`, `BOM Review`, `ECAD/MCAD Sync`, `Status`, `Artifacts`.
- [x] `T-UX-002` Basculer les répertoires utilisateur vers les hooks directs dans les forks natifs.
- [x] `Support UI/UX Ops` Publier la TUI UI/UX avec logs et purge contrôlée.
- [x] `Support UI/UX Ops` Étendre la TUI UI/UX avec `logs-list` et `logs-latest` pour lecture opératoire.
## P1
- [x] `T-UX-004` Ajouter une command palette unifiée dans les surfaces KiCad/FreeCAD déjà contrôlées par YiACAD.
- [x] `T-UX-005` Construire le `review center` avec regroupement par sévérité et provenance.
- [x] `T-UX-006` Ajouter un inspector contextuel pour détails + explications IA.
- [x] `T-UX-006` Ajouter une taxonomie visuelle stable pour `review`, `sync`, `status`, `artifacts`.
## Actif
- [x] `T-UX-003` Première montée native compilée de YiACAD dans les forks `kicad-ki` et `freecad-ki`.
- [x] `T-UX-004` Lot sûr: normaliser `command palette / inspector / review center` dans le workbench FreeCAD et le plugin KiCad, sans ouvrir les hotspots compilés.
- [x] Raccorder les docs d’entrée et runbooks à la lane YiACAD UI/UX.
## Sous-lots actifs
- [x] `T-UX-003A` Regrouper les actions YiACAD dans les toolbars shell KiCad `pcbnew` et `eeschema`.
- [x] `T-UX-003B` Stabiliser le dock workbench FreeCAD `YiACAD Inspector`.
- [x] `T-UX-003C` Unifier les helpers control-layer KiCad et documenter la symetrie PCB/SCH.
- Resultat: resolution Python YiACAD, appel direct a `yiacad_native_ops.py` et symetrie PCB/SCH alignees sur le plus petit write-set natif.
- [x] `T-UX-003D` Preparer la montee shell FreeCAD via `MainWindow.cpp` seul, sans ouvrir `DockWindowManager.cpp` ni `ComboView.cpp`.
- Avancement 2026-03-20 23:22 CET: ancrage shell compile `Std_YiACADShellView` cree dans `MainWindow.cpp`, cache par defaut, avec une premiere carte shell alignee sur le contrat YiACAD.
- [x] `T-UX-004A` Poser la palette legere et le review center dans les surfaces deja YiACAD.
- [x] `T-UX-004B` Normaliser le contrat de sortie UX commun (`done|degraded|blocked`, severite, next_steps, artifacts`).
- [x] `Support UI/UX Ops` Exposer la lane active, les owners et les preuves dans la TUI YiACAD.
## Delta 2026-03-20 16:50 CET
- `T-UX-003`: KiCad Manager expose `YiACAD Status` en menu/toolbar natifs.
- `T-UX-003`: FreeCAD expose un `YiACAD Inspector` dockable côté workbench.
- reste à faire sur `T-UX-003`: `pcbnew`, `eeschema`, palette/inspector plus profonds côté shells natifs.
- `T-UX-004`: démarrer par les surfaces déjà YiACAD avant `MainWindow.cpp`, `DockWindowManager.cpp` et `webview_panel.h`.
- `T-UX-003`: `pcbnew` et `eeschema` exposent maintenant un groupe shell `YiACAD Review` dans leurs toolbars natives.
## Delta 2026-03-20 16:10 CET
- la lane `yiacad-fusion` a validé `prepare`, `FreeCAD MCP` et `OpenSCAD MCP`
- le blocage opératoire reste `KiCad MCP host smoke`
- cause actuelle documentée: `mascarade-main` ne contient pas encore `finetune/kicad_mcp_server/dist/index.js`
- effet utile: le doctor KiCad auto retombe maintenant en `container`, mais la montée hôte native complète reste incomplète côté shells KiCad
- impact immédiat:
- `T-UX-003` reste actif tant que la smoke YiACAD n’est pas totalement verte
- `T-UX-004` à `T-UX-006` ne doivent pas absorber ce blocage et restent découplés côté UI
## P2
- [ ] `T-UX-007` Identifier puis intégrer les points d’ancrage compilés dans les forks `kicad-ki` et `freecad-ki`.
- [ ] `T-UX-007` Faire converger la toolbar sémantique native côté KiCad et FreeCAD.
- [ ] `T-UX-008` Étudier l’exposition des actions YiACAD via `App Intents`/automatisation locale.
- [ ] `T-UX-008` Qualifier l’usage d’un modèle local/on-device pour assistance de review.
## Delta 2026-03-20 - avancement T-UX-003
- [x] Exposer `YiACAD Status` dans `KiCad Manager`
- [x] Exposer `YiACAD Status` dans `pcbnew`
- [x] Exposer `YiACAD Status` dans `eeschema`
- [x] Raccorder les handlers natifs aux control layers KiCad
- [x] Remplacer le bridge local par des hooks backend YiACAD directs
- [x] Étendre les actions natives vers `ERC/DRC`, `BOM review`, `ECAD/MCAD sync`
- [x] Ouvrir `T-UX-004` avec palette de commandes et inspector persistant multi-surface
## Delta 2026-03-20 - runner natif direct
- [x] Remplacer `yiacad_ai_bridge.py` par `yiacad_native_ops.py` dans `KiCad Manager`
- [x] Remplacer `yiacad_ai_bridge.py` par `yiacad_native_ops.py` dans `pcbnew`
- [x] Remplacer `yiacad_ai_bridge.py` par `yiacad_native_ops.py` dans `eeschema`
- [x] Brancher `YiACAD Status`, `YiACAD ERC/DRC`, `YiACAD BOM Review`, `YiACAD ECAD/MCAD Sync` dans les surfaces KiCad natives
- [x] Brancher les mêmes actions sur le workbench FreeCAD via appel direct au runner YiACAD
- [ ] Remplacer le runner Python local par un backend YiACAD pleinement intégré
- [ ] Ouvrir `T-UX-004` pour palette de commandes, review center et inspector persistant multi-surface
- 2026-03-20 17:10 +0100 - lane parallele `yiacad-uiux-apple-native` activee. Explorateur `T-UX-003` assigne aux points d insertion natifs KiCad/FreeCAD; explorateur `T-UX-004` assigne a la command palette et a l inspector persistant.
- 2026-03-20 17:18 +0100 - normalisation canonique: `T-UX-003` couvre la montee native shell/workbench; la TUI UI/UX reste un support ops deja livre.
- 2026-03-20 17:18 +0100 - lot sur `T-UX-004` ouvert dans les surfaces deja YiACAD (`yiacad_freecad_gui.py`, `yiacad_action.py`) pour preparer palette, inspector et review center sans toucher aux hotspots compiles.
- 2026-03-20 18:12 +0100 - `T-UX-003` pousse un increment shell sur KiCad: regroupement des actions natives dans `pcbnew` et `eeschema` sous `YiACAD Review`.
- 2026-03-20 18:12 +0100 - agents du lot: `CAD-UX / KiCad-Shell`, `CAD-UX / FreeCAD-Shell`, `Doc-Research / OSS-Watch`.
- 2026-03-20 18:18 +0100 - garde-fou `T-UX-003`: `common/eda_base_frame.cpp` reste hors write-set; seules les surfaces editor-locales `toolbars_*` et `*_editor_control.*` sont canoniques pour ce lot.
- 2026-03-20 18:18 +0100 - risque de lot documente: runners shell KiCad synchrones et dupliques entre PCB/SCH, donc toute extension doit rester strictement symetrique.
- 2026-03-20 18:20 +0100 - garde-fou FreeCAD: write-set sûr = `yiacad_freecad_gui.py`; write-set shell compile minimal suivant = `MainWindow.cpp` seul.
- 2026-03-20 18:20 +0100 - `DockWindowManager.cpp` et `ComboView.cpp` restent hors write-set pour eviter double ownership du dock YiACAD et regression globale du shell FreeCAD.
- 2026-03-20 18:35 +0100 - sous-lots explicites ouverts: `T-UX-003A/B/C/D`, `T-UX-004A/B`, `Support UI/UX Ops`.
- 2026-03-20 18:35 +0100 - owners de tranche confirms: `KiCad-Shell`, `FreeCAD-Shell`, `KiCad-Native`, `FreeCAD-Native`, `TUI-Ops`, `OSS-Watch`.
- 2026-03-20 18:52 +0100 - `T-UX-003C` progresse avec une premiere symetrie reelle sur `board_editor_control.cpp` et `sch_editor_control.cpp`, sans ouvrir `EDA_BASE_FRAME`.
- 2026-03-20 22:46 +0100 - `Support UI/UX Ops` ferme: `yiacad_uiux_tui.sh` expose `lane-status`, `owners`, `proofs`, `logs-summary`, `logs-latest`, avec lecture operatoire rejouee.
- 2026-03-20 22:49 +0100 - `T-UX-004B` ferme: contrat de sortie UX YiACAD publie dans `docs/` + `specs/contracts/` et expose dans `yiacad_uiux_tui.sh --action proofs`.
- 2026-03-20 23:06 +0100 - `T-UX-003D` progresse: `MainWindow.cpp` cree un dock shell `Std_YiACADShellView` cache par defaut, sans ouvrir `DockWindowManager.cpp` ni `ComboView.cpp`.
- 2026-03-20 23:22 +0100 - `T-UX-003D` ferme: le dock shell FreeCAD affiche maintenant une premiere carte alignee sur le contrat YiACAD et reste pilotable via son toggle `YiACAD Shell`.
## Delta 2026-03-20 - backlog T-UX-004 structure
- [x] Produire l'audit exhaustif de refonte YiACAD
- [x] Produire la spec `T-UX-004`
- [x] Produire la feature map Mermaid `T-UX-004`
- [x] Definir le contrat de sortie UX commun pour toutes les actions YiACAD
- [ ] Monter la command palette YiACAD sur KiCad et FreeCAD
- [ ] Construire le review center unifie
- [ ] Rendre l'inspector YiACAD persistant et contextuel
- [ ] Raccorder les resultats au contexte projet et aux artefacts
## Consolidation canonique 2026-03-20
- `T-UX-003` est maintenant ferme comme lot parent; la suite shell profonde se deplace vers `T-UX-007`.
- `T-UX-004` est maintenant ferme comme lot parent:
- doc/contrat: fait
- implementation palette/review/inspector: faite sur les surfaces Python YiACAD
- prochain front structurel associe:
- consommer le `context broker` local YiACAD
- consommer `uiux_output.json`
- backend plus robuste que le runner Python direct
## Delta 2026-03-21 - T-UX-004A confirme
- [x] Palette legere livree sur plugin KiCad
- [x] Palette legere livree sur workbench FreeCAD
- [x] Review center leger branche sur `--json-output`
- [x] Entree operateur stable publiee pour arbitrer entre lane `20` et lane `21`
- [ ] Inspector persistant de session
- [ ] Review center multi-surface plus riche
## Delta 2026-03-21 - T-UX-005 confirme
- [x] Review center enrichi sur plugin KiCad
- [x] Review center enrichi sur workbench FreeCAD
- [x] Sections `Status`, `Severity`, `Summary`, `Details`, `Context`, `Artifacts`, `Next steps` en place
- [x] Fallback texte conserve
- [ ] Inspector persistant de session
- [ ] Review session persistante multi-surface
## Delta 2026-03-21 - preuve backend UI/UX
- [x] Publier une preuve operateur `KiCad + FreeCAD -> facade backend -> uiux_output`
- [x] Exposer cette preuve via `yiacad_uiux_tui.sh` et `yiacad_operator_index.sh`
- [ ] Continuer sur l'inspector persistant et la session de revue
## Delta 2026-03-21 - T-UX-006A
- [x] Persister la derniere session de revue sur les surfaces Python YiACAD
- [x] Exposer cette session via `yiacad_uiux_tui.sh --action review-session`
- [ ] Etendre cette session persistante aux shells compiles quand le write-set sera acceptable
## Delta 2026-03-21 - T-UX-006B
- [x] Persister un historique de revue YiACAD
- [x] Classer les entrees d'historique avec une taxonomie legere
- [x] Exposer l'historique via `yiacad_uiux_tui.sh` et `yiacad_operator_index.sh`
- [ ] Enrichir ensuite l'inspector persistant avec cette taxonomie et un historique plus riche
## Delta 2026-03-21 - T-UX-006C
- [x] Exposer une vue de taxonomie de revue pour l'operateur
- [x] Relayer cette vue dans l'index operateur
- [ ] Continuer ensuite sur l'inspector contextuel plus riche
## Delta 2026-03-21 - T-UX-006 confirme
- [x] Bandeau de session persistant sur plugin KiCad
- [x] En-tete de session persistant sur workbench FreeCAD
- [x] Dernier contrat et dernier `context_ref` conserves
- [x] Trajet recent / continuite de session visible
- [ ] Session de revue riche multi-vues
## Delta 2026-03-21 - backend service base
- [x] Surfaces Python YiACAD recablees sur un client backend `service-first`
- [x] Fallback direct conserve
- [ ] Extension eventuelle aux surfaces compilees plus profondes
## Delta 2026-03-21 - T-UX-006D
- [x] Exposer un contexte de revue compact cote KiCad avec taxonomie et dernieres actions
- [x] Enrichir le trail FreeCAD avec une synthese de taxonomie
- [x] Exposer `review-context` via `yiacad_uiux_tui.sh` et `yiacad_operator_index.sh`
- [ ] Continuer ensuite seulement si utile vers une session multi-vues plus profonde
## Delta 2026-03-21 - T-UX-006E
- [x] Fournir un `context_ref` deterministe pour les preuves backend meme quand le chemin source ne pointe pas encore vers un fichier existant
- [x] Recharger le backend service local pour prendre en compte ce builder de contexte
- [x] Verdir `review-context` cote header sans masquer le statut metier reel
## Delta 2026-03-21 - T-UX-006F
- [x] Remplacer les chemins de preuve temporaires par des fixtures stables suivies dans le repo
- [x] Garder le statut metier `blocked` tout en fiabilisant le contexte operateur
- [ ] Continuer ensuite vers un contexte projet plus riche que la seule fixture de preuve
## Delta 2026-03-21 - T-UX-006D
- [x] Exposer un contexte de revue synthétique dans le review center YiACAD
- [x] Relayer ce contexte via `yiacad_uiux_tui.sh --action review-context`
- [x] Relayer ce contexte via `yiacad_operator_index.sh --action review-context`
## 2026-03-21 - Lot update
- `T-ARCH-101C` etendu: les surfaces KiCad compilees passent en `service-first` via `tools/cad/yiacad_backend_client.py`, avec auto-start du service local et fallback direct vers `tools/cad/yiacad_native_ops.py`.
- `T-OPS-119` consolide: `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable avec `status`, `uiux`, `global`, `backend`, `proofs` et des alias de compatibilite conserves.
- Risque residuel: aucune validation d'execution n'a ete lancee; l'extension aux call sites compiles restants doit etre traitee dans un lot separe.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
## Delta 2026-03-21 - T-UX-003 / T-UX-004 clos
- [x] Verrouiller la presence des surfaces natives YiACAD via `test/test_yiacad_native_surface_contract.py`
- [x] Fermer `T-UX-003` comme lot parent apres verification des ancrages KiCad/FreeCAD deja livres
- [x] Fermer `T-UX-004` comme lot parent apres verification de la palette, du review center et de la persistance cote plugin/workbench
- [x] Reporter les approfondissements shell compiles sous `T-UX-007` au lieu de laisser `T-UX-003` / `T-UX-004` ouverts par inertie documentaire
docs/plans/21_plan_refonte_globale_yiacad.md
+126
View File
@@ -0,0 +1,126 @@
# Plan 21 - refonte globale YiACAD (2026-03-20)
## Intention
Construire la couche de pilotage globale qui assemble audit, IA, docs, plans, TODOs, TUI et lot suivant autour de YiACAD.
## Lanes et responsables
| Lane | Owner | Sous-agent / role | Competences | Write-set principal |
| --- | --- | --- | --- | --- |
| Audit-Core | Architect / Doc | Audit-Core | analyse repo, synthese, cartes | `docs/YIACAD_GLOBAL_*`, `specs/yiacad_global_refonte_spec.md` |
| AI-Integration | Architect / CAD | AI-Integration | MCP, CAD IA-native, orchestration | `docs/YIACAD_GLOBAL_AI_*`, `docs/YIACAD_GLOBAL_OSS_*` |
| DesignOps-UI | CAD / DesignOps | UI-Orchestrator | palette, inspector, review center | forks CAD + `docs/plans/20_*` |
| CAD-Native | CAD | KiCad-Native, FreeCAD-Native | shells natifs, backend path, context propagation | `.runtime-home/cad-ai-native-forks/*`, `tools/cad/*` |
| Ops-TUI | PM / Doc | TUI-Operator | bash TUI, logs, purge, status | `tools/cockpit/yiacad_refonte_tui.sh`, `artifacts/yiacad_refonte_tui/*` |
| Docs-Continuity | Doc | Docs-Continuity | README, runbook, index, coherence | `README.md`, `docs/index.md`, `docs/RUNBOOK.md` |
## Sequence recommandee
1. Audit global et recherche OSS
2. Spec et feature map globales
3. Plan / TODO / owners / write-sets
4. TUI globale et logs
5. Passage vers `T-UX-004`
## Risques a contenir
- dispersion documentaire
- coexistence de plusieurs TUI proches
- backend YiACAD encore trop leger
- confusion entre lane UI/UX et refonte globale
## Critere de sortie
- tout nouvel arrivant sait ou lire l'audit, la spec, le plan, le TODO, la recherche et la commande TUI d'entree
- le prochain lot est formule explicitement et sans ambiguite
## Etat canonique 2026-03-20
- bundle global publie: audit, IA, cartes, OSS, spec, plan, TODO, TUI
- lot suivant produit: `T-UX-004`
- lot suivant architecture: `T-ARCH-101C`
- lot ops ferme: `T-OPS-118`
- palier architecture livre:
- backend local `yiacad_backend.py`
- `context broker` schema + example
- `uiux_output.json` et `context.json` prepares pour les surfaces produit
- objectif de ce plan:
- eviter les deltas contradictoires
- garder une entree lisible entre refonte globale et refonte UI/UX
## Delta 2026-03-21 - T-OPS-118 operator index
- `T-OPS-118` pose une entree operateur stable: `tools/cockpit/yiacad_operator_index.sh`.
- Cette surface ne remplace pas les TUI existantes; elle route explicitement vers `yiacad_uiux_tui.sh` et `yiacad_refonte_tui.sh`.
- La commande d’entree et la doc associee deviennent auditables via `docs/YIACAD_OPERATOR_INDEX_2026-03-21.md`.
## Delta 2026-03-21 - T-ARCH-101 closure
- `T-ARCH-101` est ferme au niveau parent.
- La couche locale YiACAD est maintenant formalisee autour de:
- `tools/cad/yiacad_backend.py`
- `tools/cad/yiacad_native_ops.py`
- `tools/cad/yiacad_backend_service.py`
- Le front architecture encore actif devient `T-ARCH-101C`: reroutage progressif des shells natifs vers la facade backend locale.
## Delta 2026-03-21 - operator entrypoint
- l'entree operateur stable est maintenant `tools/cockpit/yiacad_operator_index.sh`.
- ce point d'entree route explicitement vers la lane UI/UX (`20`) et la lane globale (`21`).
## Delta 2026-03-21 - T-UX-005
- le lot produit suivant execute apres `T-UX-004A` est maintenant livre: review center enrichi sur KiCad et FreeCAD.
- l'enchainement naturel devient `T-UX-006` puis `T-ARCH-101C`.
## Delta 2026-03-21 - T-ARCH-101C tranche KiCad
- premiere tranche de reroutage shell executee sans ouvrir de hotspot compile:
- le plugin KiCad YiACAD passe maintenant par la facade locale `tools/cad/yiacad_backend_service.py`
- le fallback direct `yiacad_native_ops.py` reste en place si la facade n'est pas presente
- cette tranche ferme le plus petit write-set utile cote KiCad:
- `.runtime-home/cad-ai-native-forks/kicad-ki/scripting/plugins/yiacad_kicad_plugin/_native_common.py`
- la convergence FreeCAD vers la meme facade reste ouverte dans `T-ARCH-101C`.
## Delta 2026-03-21 - T-ARCH-101C tranche FreeCAD
- deuxieme tranche de reroutage shell executee sur le plus petit helper Python utile:
- `yiacad_freecad_gui.py` privilegie maintenant `tools/cad/yiacad_backend_service.py`
- les call sites UI FreeCAD restent inchanges; seul le transport vers le backend a ete reroute
- le fallback direct `yiacad_native_ops.py` reste disponible si la facade locale est absente.
## Delta 2026-03-21 - T-ARCH-101C preuve operateur unifiee
- un runbook canonique de preuve operateur est maintenant publie:
- `tools/cockpit/yiacad_backend_proof.sh`
- `docs/YIACAD_BACKEND_OPERATOR_PROOF_2026-03-21.md`
- cette preuve verifie:
- statut de la facade locale,
- transport shell KiCad vers la facade,
- transport workbench FreeCAD vers la facade,
- presence du contrat `uiux_output` sur les actions de preuve.
- `yiacad_uiux_tui.sh --action status` passe maintenant lui aussi par le client `service-first`.
- `T-ARCH-101C` est ferme pour les surfaces actives; les suites de travail sont reparties entre `T-UX-003`, `T-UX-004` et `T-RE-209`.
## Delta 2026-03-21 - T-UX-006
- la persistance de session de base est maintenant en place sur les deux surfaces deja YiACAD.
- l'enchainement naturel devient `T-ARCH-101C`, puis une session de revue plus riche cote produit.
## Delta 2026-03-21 - backend service
- `T-ARCH-101C` est maintenant livre sur les surfaces actives Python via un backend local et un client `service-first`.
- une surface operatoire dediee existe maintenant: `tools/cockpit/yiacad_backend_service_tui.sh`.
## Delta 2026-03-21 - T-UX-006D raccord global
- la couche produit YiACAD ajoute maintenant une vue de contexte de revue consolidée au-dessus de la session persistée et de l’historique.
- ce palier ferme un besoin opératoire utile sans ouvrir les surfaces compilées plus risquées.
## 2026-03-21 - Lot update
- `T-ARCH-101C` est maintenant ferme: les surfaces actives KiCad / FreeCAD et la TUI UI/UX passent en `service-first` via `tools/cad/yiacad_backend_client.py`, avec auto-start du service local et fallback direct vers `tools/cad/yiacad_native_ops.py`.
- `T-OPS-119` consolide: `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable avec `status`, `uiux`, `global`, `backend`, `proofs` et des alias de compatibilite conserves.
- Validation executee: `bash tools/cockpit/yiacad_backend_proof.sh --action run --json` retourne `status=done`.
- Risque residuel: l'extension aux call sites compiles restants et la persistance produit restent traitees par `T-UX-003`, `T-UX-004` et `T-RE-209`.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
docs/plans/21_todo_refonte_globale_yiacad.md
+87
View File
@@ -0,0 +1,87 @@
# TODO 21 - refonte globale YiACAD (2026-03-20)
## P0
- [x] Produire un audit global priorise du repo
- [x] Produire une evaluation des integrations IA prioritaires
- [x] Produire une feature map Mermaid globale
- [x] Produire une recherche OSS globale YiACAD
- [x] Produire une spec globale YiACAD
- [x] Ajouter une TUI globale YiACAD avec logs
- [x] Raccorder le README a ce bundle global
## P1
- [x] Formaliser le backend YiACAD cible derriere `yiacad_native_ops.py`
- [x] Publier l'architecture backend locale, le `context broker` et les contrats associes
- [x] Introduire le module `tools/cad/yiacad_backend.py` et les artefacts `context.json` / `uiux_output.json`
- [x] Ouvrir et distribuer `T-UX-004`
- [ ] Executer `T-UX-004` sur KiCad/FreeCAD (`palette`, `review center`, `inspector`)
- [x] Rationaliser les TUI proches autour d'un index operateur stable
- [ ] Resumer les zones `ai-agentic-embedded-base`, `zeroclaw`, `openclaw` dans une vue canonique unique
## P2
- [ ] Ajouter un tableau de maturite par lane
- [ ] Ajouter des KPI de densite documentaire et de fragmentation
- [ ] Faire converger logs, handoffs et resumés hebdomadaires dans une seule entree cockpit
## Consolidation canonique 2026-03-20
- `T-UX-004` n'est plus un point d'ouverture; c'est maintenant un lot d'execution.
- le point d'ouverture architecture restant est le backend YiACAD cible derriere `yiacad_native_ops.py`.
- le front architecture encore ouvert correspond maintenant au passage de backend local partage vers service/backend plus stable (`T-ARCH-101C`).
- le point d'entree operateur canonique est maintenant `bash tools/cockpit/yiacad_operator_index.sh --action status`.
## Delta 2026-03-21
- `T-OPS-118` ferme:
- `tools/cockpit/yiacad_operator_index.sh`
- `docs/YIACAD_OPERATOR_INDEX_2026-03-21.md`
- `yiacad_refonte_tui.sh` et `yiacad_uiux_tui.sh` pointent maintenant vers cet index
- `T-ARCH-101` ferme:
- `tools/cad/yiacad_backend.py`
- `tools/cad/yiacad_native_ops.py`
- `tools/cad/yiacad_backend_service.py`
- `docs/YIACAD_BACKEND_ARCHITECTURE_2026-03-20.md`
- `specs/yiacad_backend_architecture_spec.md`
## Delta 2026-03-21 - progression lots YiACAD
- `T-UX-004A` avance avec palette legere + review center leger livres sur KiCad plugin et FreeCAD workbench.
- `T-ARCH-101C` est ferme sur les surfaces actives.
- `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable.
## Delta 2026-03-21 - progression review center
- `T-UX-005` est livre.
- le prochain lot produit ouvert est `T-UX-006`.
## Delta 2026-03-21 - progression T-ARCH-101C
- [x] rerouter la jonction shell KiCad vers `yiacad_backend_service.py` via `_native_common.py`
- [x] rerouter le helper principal FreeCAD vers la meme facade backend locale
- [x] rerouter `yiacad_uiux_tui.sh --action status` sur le meme client `service-first`
- [ ] rerouter les surfaces FreeCAD compilees restantes seulement si un write-set plus large devient necessaire
- [x] publier une preuve operateur unifiee `KiCad + FreeCAD -> facade backend -> uiux output`
## Delta 2026-03-21 - progression inspector
- `T-UX-006` est livre sur les surfaces deja YiACAD.
- le front prioritaire restant remonte vers `T-ARCH-101C`.
## Delta 2026-03-21 - backend service progression
- `T-ARCH-101C` est livre sur les surfaces actives Python.
- le prochain arbitrage porte maintenant sur `T-UX-003`, `T-UX-004` et `T-RE-209`.
## Delta 2026-03-21 - T-UX-006D
- [x] Ajouter une vue de contexte de revue opérable au-dessus de la session persistée
- [x] Raccorder cette vue dans l’index opérateur global
## 2026-03-21 - Lot update
- `T-ARCH-101C` est maintenant ferme: les surfaces actives KiCad / FreeCAD et la TUI UI/UX passent en `service-first` via `tools/cad/yiacad_backend_client.py`, avec auto-start du service local et fallback direct vers `tools/cad/yiacad_native_ops.py`.
- `T-OPS-119` consolide: `tools/cockpit/yiacad_operator_index.sh` devient l'entree operateur stable avec `status`, `uiux`, `global`, `backend`, `proofs` et des alias de compatibilite conserves.
- Validation executee: `bash tools/cockpit/yiacad_backend_proof.sh --action run --json` retourne `status=done`.
- Risque residuel: l'extension aux call sites compiles restants doit etre traitee dans `T-UX-003`, et la persistance produit dans `T-UX-004`.
## 2026-03-21 - Proofs lane
- Nouveau point d'entree: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
- Objectif: centraliser `backend`, `review-session`, `review-history`, `review-taxonomy` et l'hygiene des logs dans une surface canonique sans casser les alias historiques.
- Documentation: `docs/YIACAD_PROOFS_TUI_2026-03-21.md`.
docs/plans/22_plan_integration_intelligence_agentique.md
+124
View File
@@ -0,0 +1,124 @@
# Plan 22 - integration intelligence agentique (2026-03-22)
## Intention
Le lot 22 a deja livre son socle contractuel minimal pour la gouvernance intelligence, reutilisable par les docs, le cockpit et les artefacts.
La phase active du `2026-03-22` n'est plus un lot purement documentaire: elle durcit les surfaces deja livrees (`intelligence_tui`, `runtime_ai_gateway`, `log_ops`, `refonte_tui`), remet en coherence la spec/le plan/le TODO avec la realite du code, integre une veille officielle MCP/agentique/IA exploitable dans les priorites du projet, et couvre maintenant explicitement la plateforme `web/` Git EDA YiACAD.
`owner_repo` du lot: `Kill_LIFE`
Les deux livrables canoniques du lot sont:
- `specs/contracts/summary_short.schema.json`
- `specs/contracts/runtime_mcp_ia_gateway.schema.json`
## Lanes actives
| Lane | owner_agent | owner_subagent | Competences | write_set principal | Priorite immediate |
| --- | --- | --- | --- | --- | --- |
| Program-Governance | `PM-Mesh` | `Plan-Orchestrator` | arbitrage, sequencing, lot hygiene | `specs/agentic_intelligence_integration_spec.md`, `docs/plans/22_plan_integration_intelligence_agentique.md`, `docs/plans/22_todo_integration_intelligence_agentique.md`, `specs/04_tasks.md` | rouvrir le backlog actif du lot 22 et aligner la memoire intelligence sur les nouvelles actions |
| Contracts | `Mesh-Contracts` | `Contract-View` | schemas JSON, versionnement, compatibilite | `specs/contracts/summary_short.schema.json`, `specs/contracts/runtime_mcp_ia_gateway.schema.json`, `tools/cockpit/intelligence_tui.sh`, `tools/cockpit/runtime_ai_gateway.sh` | garder les contrats stables tout en durcissant les sorties machine et les chemins canonique |
| Runtime-Gateway | `Runtime-Companion` | `MCP-Health` | sante runtime, MCP, IA, degraded-safe | `tools/cockpit/runtime_ai_gateway.sh`, `docs/AI_WORKFLOWS.md`, `specs/contracts/runtime_mcp_ia_gateway.schema.json` | fiabiliser le refresh et preparer l'integration des signaux firmware/CAD dans la gateway |
| Docs-Continuity | `Docs-Research` | `Runbook-Editor` | coherence documentaire, wording canonique, veille officielle | `README.md`, `docs/index.md`, `docs/AI_WORKFLOWS.md`, `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md` | realigner le lot 22 avec la realite livree et mettre a jour les recommandations 2026 depuis les sources officielles |
| QA-Compliance | `QA-Compliance` | `Evidence-Pack` | evidence minimale, lisibilite automation, tests shell/TUI | `tools/cockpit/refonte_tui.sh`, `tools/cockpit/log_ops.sh`, `test/test_intelligence_tui_contract.py`, `test/test_log_ops_contract.py` | corriger les garde-fous de purge, fiabiliser les sorties JSON et etendre la couverture de test |
| Firmware-CAD-Bridge | `Arch-Mesh` | `CAD-Bridge` | firmware, CAD, MCP, evidence bridge | `firmware/*`, `tools/hw/*`, `tools/ai/zeroclaw_hw_firmware_loop.sh`, `mcp.json` | decider le chemin firmware canonique et preparer la remontee firmware/CAD dans les contrats intelligence |
| Web-Git-EDA-Overlay | `Web-CAD-Platform` | `Realtime-Collab` | Next.js produit, GraphQL, Yjs, BullMQ, Git-first review, MCP/service-first AI | `specs/yiacad_git_eda_platform_spec.md`, `docs/plans/23_plan_yiacad_git_eda_platform.md`, `docs/plans/23_todo_yiacad_git_eda_platform.md`, `docs/YIACAD_GIT_EDA_PLATFORM_2026-03-22.md`, `web/*` | aligner le backlog web avec la gouvernance intelligence et ouvrir le read model Git/CI/artifacts reel |
## Contrats attendus
### 1. `summary-short/v1`
But:
- publier une synthese courte stable d'un lot ou d'une lane
- rester exploitable dans une vue cockpit, un log, un `latest.json` ou une note d'handoff
Champs minimum:
- `contract_version`
- `generated_at`
- `component`
- `owner_repo`
- `owner_agent`
- `owner_subagent`
- `write_set`
- `status`
- `summary_short`
- `evidence`
### 2. `runtime-mcp-ia-gateway/v1`
But:
- exposer un etat global unique pour la sante intelligence
- rendre explicite quel sous-ensemble degrade entre `runtime`, `mcp` et `ia`
Champs minimum:
- `contract_version`
- `generated_at`
- `component`
- `owner_repo`
- `owner_agent`
- `owner_subagent`
- `write_set`
- `status`
- `summary_short`
- `evidence`
- `surfaces.runtime`
- `surfaces.mcp`
- `surfaces.ia`
## Sequence recommandee
1. realigner la spec, le plan, le TODO et `specs/04_tasks.md` sur la realite du lot 22 deja livre
2. durcir les surfaces cockpit deja en place (`refonte_tui`, `log_ops`, `intelligence_tui`)
3. rafraichir la veille officielle MCP/agentique/IA et convertir la veille en decisions d'adoption explicites
4. raccorder explicitement `specs/yiacad_git_eda_platform_spec.md`, `docs/plans/23_*`, `docs/YIACAD_GIT_EDA_PLATFORM_2026-03-22.md` et `web/README.md` a la memoire intelligence
5. rouvrir les prochaines actions firmware/CAD/MCP et web Git EDA a partir de l'audit exhaustif
6. rafraichir la memoire `intelligence_tui` et la gateway `runtime/mcp/ia` apres chaque passe structurante
## Decisions actees 2026-03-21
### Politique miroir
- `Kill_LIFE/specs/` est canonique; `ai-agentic-embedded-base/specs/` est un miroir exporte.
- Les surfaces `docs/`, `tools/`, `artifacts/` et `firmware/` restent root-first dans `Kill_LIFE`.
- La discipline de fermeture pour les lots spec-first est: modifier `specs/`, synchroniser le miroir, puis valider en `--require-mirror-sync`.
### Chemin firmware prioritaire
- Le chemin firmware executable prioritaire reste `firmware/platformio.ini` avec `firmware/src/main.cpp`.
- La stack `voice_controller` reste en pre-integration tant qu'elle n'est ni branchee au `main.cpp`, ni couverte par une boucle de build/test/release explicite.
- Le raccord futur a `summary-short/v1` et `runtime-mcp-ia-gateway/v1` doit partir des preuves du `firmware/` racine, puis ajouter les statuts `voice`/`cad` seulement apres preuve exploitable.
## Evidence minimale du lot
- la spec de lot est a jour et ne contredit plus l'existence des TUIs/tests deja livres
- le plan 22 et le TODO 22 portent des actions ouvertes exploitables par `intelligence_tui`
- le plan 23 et le TODO 23 remontent aussi dans la memoire et les `next_steps`
- `docs/AI_WORKFLOWS.md` reference les contrats et les garde-fous operatoires effectivement en place
- les corrections cockpit critiques sont couvertes par des tests ciblés ou une verification manuelle explicite
- la veille officielle 2026 est documentee avec dates, sources et decisions d'adoption
## Risques a contenir
- confusion entre `cockpit-v1` et les nouveaux contrats de gouvernance
- inflation de schemas si `summary-short` devient un dump complet au lieu d'un resume court
- overlap non explicite entre sante globale mesh et sante `runtime/mcp/ia`
- backlog faux-negatif si le TODO 22 reste tout en `[x]`
- backlog faux-negatif si le plan 23 reste hors memoire intelligence
- purge non interactive trop permissive dans les TUIs
- derive entre repo racine et miroir `ai-agentic-embedded-base`
- confusion entre firmware executable canonique et stack voice encore non branchee
- glissement entre demo `web/` locale et plateforme Git-first multi-tenant si le read model Git/CI/artefacts n'est pas documente comme backlog ouvert
## Critere de sortie
- les deux schemas versionnes existent et restent les contrats de reference
- les lanes actives ont un `owner_agent`, un `owner_subagent`, un `write_set` et une priorite immediate coherente
- `docs/AI_WORKFLOWS.md`, le plan 22, le TODO 22, le plan 23, le TODO 23 et `specs/04_tasks.md` racontent la meme phase de travail
- `intelligence_tui` remonte des actions ouvertes utiles au lieu d'un faux statut termine
- les purges non interactives exigent un opt-in explicite et les sorties JSON critiques restent parseables
- les docs suffisent a reconstruire les contrats et les artefacts sans lire le shell
docs/plans/22_todo_integration_intelligence_agentique.md
+103
View File
@@ -0,0 +1,103 @@
# TODO 22 - integration intelligence agentique (2026-03-21)
## P0
- [x] Publier une spec technique dediee a l'integration intelligence agentique
- [x] Publier une feature map Mermaid dediee
- [x] Publier un plan 22 avec lanes, owners, write-sets et priorites
- [x] Ajouter une TUI cockpit dediee avec logs, memoire et contrat JSON
- [x] Raccorder la nouvelle surface a `refonte_tui.sh`
- [x] Mettre a jour `docs/index.md`, `tools/cockpit/README.md` et `docs/AI_WORKFLOWS.md`
- [x] Ajouter un test de contrat pour la nouvelle TUI
- [x] Ajouter une vue `next-actions` deduite des TODOs ouverts
## P1
- [x] Raccorder la TUI aux resynchronisations `lot_chain` si un write-set evolue
- [x] Ajouter une synthese JSON courte pour consommation par les extensions terminales/VS Code
- [x] Rendre le bridge runtime/MCP plus lisible dans une source unique
## P2
- [x] Ajouter un score de fragmentation documentaire et un score de maturite par lane
- [x] Ajouter une vue de comparaison entre `Kill_LIFE`, `ai-agentic-embedded-base` et les trois extensions
- [x] Introduire une file de recommandations IA priorisee a partir de la veille et de l'audit
## Cycle 2 - audit exhaustif et durcissement (ouvert)
### P0
- [x] Realigner `specs/agentic_intelligence_integration_spec.md`, `docs/plans/22_plan_integration_intelligence_agentique.md`, `docs/AI_WORKFLOWS.md` et `specs/04_tasks.md` sur la realite du lot 22 livre
- [x] Rouvrir des actions utiles dans `TODO 22` pour que `intelligence_tui` remonte un backlog vivant et non un faux statut termine
- [x] Durcir `tools/cockpit/refonte_tui.sh` pour exiger `--yes-auto` sur `clean-logs` non interactif
- [x] Durcir `tools/cockpit/log_ops.sh` pour garantir des sorties JSON parseables meme avec des chemins atypiques
- [x] Rendre `tools/cockpit/intelligence_tui.sh` stable hors `cwd` du repo et reduire la fragilite aux chemins dates
### P1
- [x] Rafraichir `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md` depuis les sources officielles MCP, VS Code AI extensibility, OpenAI Agents SDK et LangGraph
- [x] Documenter explicitement les decisions d'adoption 2026 avec dates et liens source dans `docs/AI_WORKFLOWS.md`
- [x] Ajouter une passe de test ou verification ciblee pour les corrections cockpit introduites dans ce cycle
- [x] Formaliser la politique racine vs miroir `ai-agentic-embedded-base` pour les surfaces docs/specs/outils qui derivent
### P2
- [x] Decider le chemin firmware canonique (`main.cpp` minimal vs stack voice) et rattacher cette decision au plan intelligence
- [x] Preparer la remontee des statuts firmware/CAD vers les contrats `summary-short/v1` et `runtime-mcp-ia-gateway/v1`
- [x] Evaluer si `runtime_ai_gateway.sh --refresh` doit degrad-er vite en cas de probes runtime/mesh trop longues
## Evidences
- `specs/agentic_intelligence_integration_spec.md`
- `docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-21.md`
- `docs/plans/22_plan_integration_intelligence_agentique.md`
- `tools/cockpit/intelligence_tui.sh`
- `tools/cockpit/intelligence_program_tui.sh`
- `tools/cockpit/runtime_ai_gateway.sh`
- `tools/cockpit/lot_chain.sh`
- `tools/autonomous_next_lots.py`
- `artifacts/cockpit/intelligence_program/latest.json`
- `artifacts/cockpit/intelligence_program/latest.md`
- `artifacts/cockpit/intelligence_program/scorecard_latest.json`
- `artifacts/cockpit/intelligence_program/scorecard_latest.md`
- `artifacts/cockpit/intelligence_program/repo_comparison_latest.json`
- `artifacts/cockpit/intelligence_program/repo_comparison_latest.md`
- `artifacts/cockpit/intelligence_program/recommendation_queue_latest.json`
- `artifacts/cockpit/intelligence_program/recommendation_queue_latest.md`
- `test/test_intelligence_tui_contract.py`
- `test/test_runtime_ai_gateway_contract.py`
## Cycle 3 - integration intelligence 2026 pour la plateforme web Git EDA (ouvert)
### P0
- [x] Etendre `tools/cockpit/intelligence_tui.sh` pour couvrir `specs/yiacad_git_eda_platform_spec.md`, `docs/plans/23_*`, `docs/YIACAD_GIT_EDA_PLATFORM_2026-03-22.md` et `web/README.md`.
- [x] Publier un audit, une veille et une feature map `2026-03-22` alignes sur la plateforme `web/` et l'overlay MCP/agentique/IA.
- [x] Affecter explicitement les owners/subagents `Web-CAD-Platform`, `Realtime-Collab`, `EDA-CI-Orchestrator` et `Review-Assist` dans les plans et la matrice agentique.
### P1
- [x] Raccorder `docs/AI_WORKFLOWS.md`, `docs/index.md`, `README.md` et `tools/cockpit/README.md` au backlog commun `TODO 22 + TODO 23`.
- [ ] Faire remonter le statut `queue/worker/realtime` du produit web dans la memoire intelligence et preparer son pont vers `runtime_ai_gateway.sh`.
- [x] Remplacer les placeholders Git/PR/artifacts de `web/` par un read model derive de Git et de la CI reelle.
### P2
- [ ] Binder la scene Excalidraw a `Yjs` tout en gardant le save manuel comme snapshot Git.
- [ ] Formaliser le boundary `MCP/service-first` pour `EDA worker`, `parts search`, `CI trigger`, `artifact fetch` et `review hints`.
## Evidence cycle 3
- `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md`
- `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-22.md`
- `docs/AGENTIC_INTELLIGENCE_FEATURE_MAP_2026-03-22.md`
- `specs/agentic_intelligence_integration_spec.md`
- `specs/yiacad_git_eda_platform_spec.md`
- `docs/plans/22_plan_integration_intelligence_agentique.md`
- `docs/plans/23_plan_yiacad_git_eda_platform.md`
- `docs/plans/23_todo_yiacad_git_eda_platform.md`
- `docs/AI_WORKFLOWS.md`
- `docs/plans/12_plan_gestion_des_agents.md`
- `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
- `tools/cockpit/intelligence_tui.sh`
- `tools/cockpit/README.md`
docs/plans/23_plan_integration_mistral_agents 2.md
+81
View File
@@ -0,0 +1,81 @@
# Plan 23 — Intégration Mistral Agents dans l'écosystème saillant.cc
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-21
> **Statut**: 🟢 Lancé
> **Dépendances**: Lot 22 (intelligence agentique), Mascarade providers
---
## Objectif
Intégrer 4 agents Mistral spécialisés dans l'écosystème saillant.cc :
- **Sentinelle** (Ops/Monitoring) — diagnostic infra via Mascarade/Langfuse/Grafana/Docker
- **Tower** (Commercial) — scoring leads, rédaction, CRM
- **Forge** (Fine-tune) — pilotage pipeline DPO/SimPO/KTO sur données KiCad/SPICE
- **Devstral** (Code) — dev workflow avec GitHub/Linear/Docker CI
## Architecture cible
```
Mascarade Router ──→ Mistral Agents API
├── Sentinelle (mistral-medium) ──→ Langfuse, Grafana, Docker
├── Tower (mistral-large) ──→ Outline, CRM/PostgreSQL
├── Forge (codestral) ──→ Fine-tune pipeline, datasets
└── Devstral (devstral) ──→ GitHub, Linear, Docker exec
```
## Phases
### Phase 0 — Fondations (J1-J4) — P0
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 1 | Créer les 4 agents sur console.mistral.ai | PM | 4 agents configurés | [ ] |
| 2 | Implémenter `mistral_agents_api.py` provider dans Mascarade | Architect + Builder | Provider fonctionnel | [ ] |
| 3 | Tests handoff inter-agents | QA | Suite de tests | [ ] |
| 4 | Déployer `mistral_agents_tui.sh` cockpit | Doc | Script opérationnel | [x] |
| 5 | Déployer `integration_health_tui.sh` cockpit | Doc | Script opérationnel | [x] |
### Phase 1 — Branchements (J5-J10) — P1
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 6 | Brancher Sentinelle sur API Mascarade /health /providers /metrics | Ops + Builder | Monitoring actif | [ ] |
| 7 | Brancher Sentinelle sur Langfuse traces + Grafana | Ops | Dashboard | [ ] |
| 8 | Configurer Tower avec Outline search + template emails | Builder | Pipeline scoring | [ ] |
| 9 | Audit qualité des 10 datasets fine-tune | QA + Forge | Rapport qualité | [ ] |
| 10 | Lancer fine-tune KiCad sur Mistral Studio | Forge | Modèle v1 | [ ] |
### Phase 2 — Production (J11-J14) — P2
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 11 | Intégrer Devstral dans workflow CI/CD | Architect + Devstral | PR automation | [ ] |
| 12 | Benchmark fine-tune: base vs KiCad-tuned (100 prompts) | QA + Forge | Rapport benchmark | [ ] |
| 13 | Documentation complète dans Outline wiki | Doc | 4 pages wiki | [ ] |
| 14 | Cron health-check Sentinelle (06:00 daily) | Ops | Cron configuré | [ ] |
## Critères de succès
- 4/4 agents déployés et fonctionnels sur Mistral Studio
- Handoff inter-agents validé (Sentinelle → Devstral pour fix auto)
- Fine-tune KiCad : accuracy >85% sur benchmark domaine
- Health-check automatique : 0 faux positifs sur 7 jours
- TUI cockpit intégré dans `yiacad_operator_index.sh`
## Risques
| Risque | Impact | Mitigation |
|--------|--------|-----------|
| API Mistral Agents en beta, breaking changes | Élevé | Abstraire via provider Mascarade, versionner |
| Qualité datasets insuffisante pour fine-tune | Moyen | Audit P1 avant lancement fine-tune |
| Coût API Mistral en production | Moyen | Monitoring via Sentinelle, fallback Ollama |
| Latence handoff inter-agents >5s | Faible | Circuit breaker Mascarade |
## Référence
- Master Integration Plan: `MASTER_INTEGRATION_PLAN_2026-03-21.md`
- Mistral Agents API: https://docs.mistral.ai/agents/introduction
- MCP 2026 best practices: topologie fédérée, pas de god-orchestrator
- LangGraph state persistence: PostgresSaver pour crash recovery
docs/plans/23_plan_integration_mistral_agents 3.md
+81
View File
@@ -0,0 +1,81 @@
# Plan 23 — Intégration Mistral Agents dans l'écosystème saillant.cc
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-21
> **Statut**: 🟢 Lancé
> **Dépendances**: Lot 22 (intelligence agentique), Mascarade providers
---
## Objectif
Intégrer 4 agents Mistral spécialisés dans l'écosystème saillant.cc :
- **Sentinelle** (Ops/Monitoring) — diagnostic infra via Mascarade/Langfuse/Grafana/Docker
- **Tower** (Commercial) — scoring leads, rédaction, CRM
- **Forge** (Fine-tune) — pilotage pipeline DPO/SimPO/KTO sur données KiCad/SPICE
- **Devstral** (Code) — dev workflow avec GitHub/Linear/Docker CI
## Architecture cible
```
Mascarade Router ──→ Mistral Agents API
├── Sentinelle (mistral-medium) ──→ Langfuse, Grafana, Docker
├── Tower (mistral-large) ──→ Outline, CRM/PostgreSQL
├── Forge (codestral) ──→ Fine-tune pipeline, datasets
└── Devstral (devstral) ──→ GitHub, Linear, Docker exec
```
## Phases
### Phase 0 — Fondations (J1-J4) — P0
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 1 | Créer les 4 agents sur console.mistral.ai | PM | 4 agents configurés | [x] |
| 2 | Implémenter `mistral_agents_api.py` provider dans Mascarade | Architect + Builder | Provider fonctionnel | [x] |
| 3 | Tests handoff inter-agents | QA | Suite de tests | [x] |
| 4 | Déployer `mistral_agents_tui.sh` cockpit | Doc | Script opérationnel | [x] |
| 5 | Déployer `integration_health_tui.sh` cockpit | Doc | Script opérationnel | [x] |
### Phase 1 — Branchements (J5-J10) — P1
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 6 | Brancher Sentinelle sur API Mascarade /health /providers /metrics | Ops + Builder | Monitoring actif | [x] |
| 7 | Brancher Sentinelle sur Langfuse traces + Grafana | Ops | Dashboard | [x] |
| 8 | Configurer Tower avec Outline search + template emails | Builder | Pipeline scoring | [~] |
| 9 | Audit qualité des 10 datasets fine-tune | QA + Forge | Rapport qualité | [x] |
| 10 | Lancer fine-tune KiCad sur Mistral Studio | Forge | Modèle v1 | [ ] |
### Phase 2 — Production (J11-J14) — P2
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 11 | Intégrer Devstral dans workflow CI/CD | Architect + Devstral | PR automation | [ ] |
| 12 | Benchmark fine-tune: base vs KiCad-tuned (100 prompts) | QA + Forge | Rapport benchmark | [ ] |
| 13 | Documentation complète dans Outline wiki | Doc | 4 pages wiki | [ ] |
| 14 | Cron health-check Sentinelle (06:00 daily) | Ops | Cron configuré | [ ] |
## Critères de succès
- 4/4 agents déployés et fonctionnels sur Mistral Studio
- Handoff inter-agents validé (Sentinelle → Devstral pour fix auto)
- Fine-tune KiCad : accuracy >85% sur benchmark domaine
- Health-check automatique : 0 faux positifs sur 7 jours
- TUI cockpit intégré dans `yiacad_operator_index.sh`
## Risques
| Risque | Impact | Mitigation |
|--------|--------|-----------|
| API Mistral Agents en beta, breaking changes | Élevé | Abstraire via provider Mascarade, versionner |
| Qualité datasets insuffisante pour fine-tune | Moyen | Audit P1 avant lancement fine-tune |
| Coût API Mistral en production | Moyen | Monitoring via Sentinelle, fallback Ollama |
| Latence handoff inter-agents >5s | Faible | Circuit breaker Mascarade |
## Référence
- Master Integration Plan: `MASTER_INTEGRATION_PLAN_2026-03-21.md`
- Mistral Agents API: https://docs.mistral.ai/agents/introduction
- MCP 2026 best practices: topologie fédérée, pas de god-orchestrator
- LangGraph state persistence: PostgresSaver pour crash recovery
docs/plans/23_plan_integration_mistral_agents.md
+81
View File
@@ -0,0 +1,81 @@
# Plan 23 — Intégration Mistral Agents dans l'écosystème saillant.cc
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-21
> **Statut**: 🟢 Phase 0 DONE — Phase 1/2 en cours (13/20 tâches)
> **Dépendances**: Lot 22 (intelligence agentique), Mascarade providers
---
## Objectif
Intégrer 4 agents Mistral spécialisés dans l'écosystème saillant.cc :
- **Sentinelle** (Ops/Monitoring) — diagnostic infra via Mascarade/Langfuse/Grafana/Docker
- **Tower** (Commercial) — scoring leads, rédaction, CRM
- **Forge** (Fine-tune) — pilotage pipeline DPO/SimPO/KTO sur données KiCad/SPICE
- **Devstral** (Code) — dev workflow avec GitHub/Linear/Docker CI
## Architecture cible
```
Mascarade Router ──→ Mistral Agents API
├── Sentinelle (mistral-medium) ──→ Langfuse, Grafana, Docker
├── Tower (mistral-large) ──→ Outline, CRM/PostgreSQL
├── Forge (codestral) ──→ Fine-tune pipeline, datasets
└── Devstral (devstral) ──→ GitHub, Linear, Docker exec
```
## Phases
### Phase 0 — Fondations (J1-J4) — P0
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 1 | Créer les 4 agents sur console.mistral.ai | PM | 4 agents configurés | [x] |
| 2 | Implémenter `mistral_agents_api.py` provider dans Mascarade | Architect + Builder | Provider fonctionnel | [x] |
| 3 | Tests handoff inter-agents | QA | Suite de tests | [x] |
| 4 | Déployer `mistral_agents_tui.sh` cockpit | Doc | Script opérationnel | [x] |
| 5 | Déployer `integration_health_tui.sh` cockpit | Doc | Script opérationnel | [x] |
### Phase 1 — Branchements (J5-J10) — P1
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 6 | Brancher Sentinelle sur API Mascarade /health /providers /metrics | Ops + Builder | Monitoring actif | [x] |
| 7 | Brancher Sentinelle sur Langfuse traces + Grafana | Ops | Dashboard | [x] |
| 8 | Configurer Tower avec Outline search + template emails | Builder | Pipeline scoring | [~] |
| 9 | Audit qualité des 10 datasets fine-tune | QA + Forge | Rapport qualité | [x] |
| 10 | Lancer fine-tune KiCad sur Mistral Studio | Forge | Modèle v1 | [ ] |
### Phase 2 — Production (J11-J14) — P2
| # | Tâche | Agent BMAD | Livrable | Done |
|---|-------|-----------|----------|------|
| 11 | Intégrer Devstral dans workflow CI/CD | Architect + Devstral | PR automation | [x] |
| 12 | Benchmark fine-tune: base vs KiCad-tuned (100 prompts) | QA + Forge | Rapport benchmark | [ ] |
| 13 | Documentation complète dans Outline wiki | Doc | 4 pages wiki | [ ] |
| 14 | Cron health-check Sentinelle (06:00 daily) | Ops | Cron configuré | [x] |
## Critères de succès
- 4/4 agents déployés et fonctionnels sur Mistral Studio
- Handoff inter-agents validé (Sentinelle → Devstral pour fix auto)
- Fine-tune KiCad : accuracy >85% sur benchmark domaine
- Health-check automatique : 0 faux positifs sur 7 jours
- TUI cockpit intégré dans `yiacad_operator_index.sh`
## Risques
| Risque | Impact | Mitigation |
|--------|--------|-----------|
| API Mistral Agents en beta, breaking changes | Élevé | Abstraire via provider Mascarade, versionner |
| Qualité datasets insuffisante pour fine-tune | Moyen | Audit P1 avant lancement fine-tune |
| Coût API Mistral en production | Moyen | Monitoring via Sentinelle, fallback Ollama |
| Latence handoff inter-agents >5s | Faible | Circuit breaker Mascarade |
## Référence
- Master Integration Plan: `MASTER_INTEGRATION_PLAN_2026-03-21.md`
- Mistral Agents API: https://docs.mistral.ai/agents/introduction
- MCP 2026 best practices: topologie fédérée, pas de god-orchestrator
- LangGraph state persistence: PostgresSaver pour crash recovery
docs/plans/23_plan_yiacad_git_eda_platform.md
+63
View File
@@ -0,0 +1,63 @@
# Plan 23 - YiACAD Git EDA platform
## Goal
Turn YiACAD into a Git-native web EDA platform with a credible path from viewer and CI to review, collaboration, and eventual browser editing.
## Workstreams
### WS1 - Git core
- self-hosted repo integration
- project-per-repo model
- tenant and namespace boundaries
### WS2 - EDA engine
- queue contract
- worker contract
- KiCad CLI, KiBot, KiAuto runner envelope
### WS3 - Product web
- dashboard
- diagram editor
- PCB viewer
- PR review
### WS4 - Realtime
- Yjs room model
- websocket deployment
- comments and presence
### WS5 - Data and parts
- graph metadata
- component indexing
- pricing and sourcing lane
### WS6 - Intelligence overlay
- review hints in read-only mode
- MCP or service-first tool boundaries for CI, artifacts, parts and ops summary
- health bridge from workers and realtime into the intelligence lane
## Immediate scope
- finish MVP surfaces
- keep Git as source of truth
- keep GraphQL small and explicit
- avoid premature browser-side EDA editing
- keep AI assist as overlay, not as source of truth
## 2026-03-22 status
- `web/` dependencies install cleanly and `next build` passes
- KiCanvas is vendored from the official bundle path into `web/public/vendor/kicanvas.js`
- the queue path is now Redis-backed through `BullMQ`
- `web/workers/eda-worker.mjs` is the first real worker entry for `kicad-headless`, `kibot`, `kiauto-checks`, and `step-export`
- project/review state is now derived from a local Git read model instead of static `.ci/pull-requests.json`
- artifacts are now exposed through a dedicated `/api/artifacts/*` route and surfaced as web links in the product
- remaining hard blocker for runtime validation is external infra: a live Redis instance and actual KiCad/KiBot/KiAuto binaries/config
- the open product gap is now the read model: real Git/PR state, live artifact URLs, Yjs scene binding, and an intelligence overlay that stays read-only
docs/plans/23_todo_integration_mistral_agents 2.md
+153
View File
@@ -0,0 +1,153 @@
# TODO 23 — Intégration Mistral Agents
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-21
> **Dernière MAJ**: 2026-03-21 (session 4)
> **Dernière MAJ**: 2026-03-22 (session 5)
> **Statut global**: 🟢 Phase 0 DONE — Phase 1 DONE — Phase 2 quasi-done (19/24) — Migration Beta API en cours — Agents AI Studio v2 configurés
---
## P0 — Fondations (URGENT)
- [x] T-MA-001: Rédiger specs des 4 agents (Sentinelle, Tower, Forge, Devstral) → `MASTER_INTEGRATION_PLAN_2026-03-21.md`
- [x] T-MA-002: Créer `mistral_agents_tui.sh` dans tools/cockpit/
- [x] T-MA-003: Créer `integration_health_tui.sh` dans tools/cockpit/
- [x] T-MA-004: Créer les 4 agents sur console.mistral.ai/build/agents
- [x] Sentinelle (mistral-medium-latest, temp=0.1) → ag_019d124c302375a8bf06f9ff8a99fb5f
- [x] Tower (magistral-medium-latest, temp=0.4) → ag_019d124e760877359ad3ff5031179ebc
- [x] Forge (codestral-latest, temp=0.2) → ag_019d1251023f73258b80ac73f90458f6
- [x] Devstral (devstral-latest, temp=0.15) → ag_019d125348eb77e880df33acbd395efa
- [x] T-MA-005: Implémenter `mistral_agents_api.py` provider dans `core/mascarade/router/providers/`
- [x] T-MA-006: Ajouter config agents dans `mascarade/.env` (MISTRAL_AGENTS_API_KEY, agent IDs)
## P1 — Branchements
- [x] T-MA-010: Brancher Sentinelle → Mascarade API (/health, /providers, /metrics) → `sentinelle_connector.py`
- [x] T-MA-011: Brancher Sentinelle → Langfuse (traces, scores, latence) → `sentinelle_connector.py`
- [x] T-MA-012: Brancher Sentinelle → Grafana (Prometheus queries: CPU, RAM, disk) → `sentinelle_connector.py`
- [x] T-MA-013: Configurer Tower → Outline search (docs produit, formations) → `tower_outline_connector.py`
- [x] T-MA-014: Configurer Tower → template emails (premier contact, follow-up, proposal) → `tower_templates.py`
- [x] T-MA-015: Audit qualité des 10 datasets fine-tune → `dataset_audit_tui.sh` (cockpit)
- [ ] build_kicad_dataset.py
- [ ] build_spice_dataset.py
- [ ] build_freecad_dataset.py
- [ ] build_stm32_dataset.py
- [ ] build_embedded_dataset.py
- [ ] build_iot_dataset.py
- [ ] build_emc_dataset.py
- [ ] build_dsp_dataset.py
- [ ] build_power_dataset.py
- [ ] build_platformio_dataset.py
- [ ] T-MA-016: Lancer fine-tune Mistral Small sur dataset KiCad fusionné (~15k examples)
- [ ] T-MA-017: Lancer fine-tune Codestral sur dataset SPICE+embedded (~20k examples)
## P2 — Production & CI/CD
- [x] T-MA-020: Intégrer Devstral dans workflow CI → `devstral-review.yml` (GitHub Actions PR review)
- [ ] T-MA-021: Benchmark comparatif: base model vs fine-tuned sur 100 prompts métier
- [x] T-MA-022: Cron Sentinelle health-check (06:00 daily) → `sentinelle_cron.sh`
- [ ] T-MA-023: Documentation dans Outline wiki (4 pages: Sentinelle, Tower, Forge, Devstral)
- [x] T-MA-024: Intégrer `mistral_agents_tui.sh` dans `yiacad_operator_index.sh` → 7 new actions (agents-status/chat/health/e2e, studio-status/files/finetune)
- [x] T-MA-025: Tests d'intégration end-to-end (handoff Sentinelle → Devstral → fix auto) → `e2e_agents_test.sh`
## P2bis — Migration API (CRITIQUE)
- [x] T-MA-035: Créer `mistral_agents_beta_api.py` — client Beta Conversations API avec fallback deprecated
- [x] MistralBetaAgentsClient: chat(), chat_deprecated(), chat_with_fallback()
- [x] Pattern Handoff intégré (handoff from→to)
- [x] MistralLibraryClient pour Document Library RAG (Tower)
- [x] Health check avec ping de tous les agents
- [x] CLI test (health, chat, handoff, libraries)
- [x] T-MA-036: Mettre à jour `e2e_agents_test.sh` — support Beta API + fallback deprecated
- [x] call_agent() refactoré avec _call_api() → conversations/completions puis agents/completions
- [x] Option --api-mode (beta|deprecated)
- [x] Rapport JSON inclut api_mode
- [ ] T-MA-037: Migrer `mistral_agents_tui.sh` vers Beta Conversations API
- [ ] T-MA-038: Migrer `mistral_agents_api.py` (Mascarade provider) vers Beta API
## P3 — Évolutions futures
- [ ] T-MA-030: Implémenter A2A protocol dans Mascarade (MCP + A2A complémentaires)
- [ ] T-MA-031: Migrer orchestrateur Mascarade vers graph-based state (LangGraph-compatible)
- [ ] T-MA-032: Ajouter RAG Document Library à Tower (Outline + docs PDF) — via MistralLibraryClient
- [ ] T-MA-033: Pipeline d'évaluation continue des agents (weekly benchmark)
- [ ] T-MA-034: Étendre lot_chain.sh avec dispatch vers agents Mistral
---
## Journal de bord
### 2026-03-21
- Création du lot 23
- Specs des 4 agents rédigées dans MASTER_INTEGRATION_PLAN
- TUI `mistral_agents_tui.sh` et `integration_health_tui.sh` déployés dans cockpit
- Recherche web effectuée : Mistral Agents API, MCP 2026, LangGraph 2026
- Matrice agent × tâche établie avec dépendances critiques
- **4 agents créés sur console.mistral.ai** avec IDs réels :
- Sentinelle: ag_019d124c302375a8bf06f9ff8a99fb5f (mistral-medium, temp 0.1)
- Tower: ag_019d124e760877359ad3ff5031179ebc (magistral-medium, temp 0.4)
- Forge: ag_019d1251023f73258b80ac73f90458f6 (codestral, temp 0.2)
- Devstral-Code: ag_019d125348eb77e880df33acbd395efa (devstral, temp 0.15)
- `mistral_agents_api.py` provider implémenté et mis à jour avec les 4 IDs
- Note: mistral-large indisponible dans agents → Tower utilise magistral-medium (meilleur raisonnement dispo)
- **Session 2 — Phase 1 :**
- `sentinelle_connector.py` créé : 7 tools MCP (mascarade_health, mascarade_providers, mascarade_metrics, langfuse_traces, langfuse_scores, prometheus queries, full_diagnostic)
- `tower_templates.py` créé : 7 templates emails (premier_contact_inbound/outbound, followup_post_demo, proposition_commerciale, formation_kicad, relance_30j/60j)
- `dataset_audit_tui.sh` créé : audit statique des 10 builders (score/8, couverture, validation, dedup, balance)
- `test_mistral_agents_provider.py` créé : 20+ tests unitaires (registry, provider, complete, handoff, health_check, singleton) + tests d'intégration
- `.env.example` mis à jour avec les 4 agent IDs
- Note: virtiofs EDEADLK deadlock persiste sur fichiers existants du repo — nouveaux fichiers OK
- `devstral-review.yml` créé : GitHub Actions workflow pour code review automatique par Devstral sur PRs
- `sentinelle_cron.sh` créé : cron daily health-check avec analyse Sentinelle + alerting webhook
- **Bilan session 2** : P0 6/6 ✅ | P1 5/8 (63%) | P2 2/6 (33%) | Total 13/20 tâches complétées
- **Session 3 — Analyse exhaustive + Lot 24 :**
- Exploration complète Mistral AI Studio (Playground, Agents, Batches, IA Documentaire, Audio offline+realtime, Fine-tune Modèles+Jobs, Fichiers, Vibe CLI, Codestral)
- Analyse exhaustive Kill_LIFE (47 scripts, 22 plans, 6 agents BMAD, 15+ schemas JSON)
- Analyse exhaustive Mascarade (10+ providers, 15+ services Docker, 10 builders fine-tune)
- Recherche web état de l'art 2026 (MCP, A2A, LangGraph, n8n, fine-tune ORPO/KTO, frameworks agentiques)
- Document `ANALYSE_EXHAUSTIVE_ECOSYSTEME_2026-03-21.md` généré (diagrammes Mermaid, feature maps, matrice agents)
- `mistral_studio_tui.sh` créé (14 actions couvrant toute la console Mistral Studio)
- Lot 24 plan + TODO créés (16 tâches, 4 phases: Fichiers, Fine-tune, Intégrations Studio, Production)
- **Chaînage** : Lot 23 → Lot 24 (Intégration Mistral Studio Complète)
- **Session 4 — Exécution Lot 23 restant + Pipeline Lot 24 :**
- `tower_outline_connector.py` créé : OutlineConnector (sync+async) avec 5 MCP tools (search, get_document, product_lookup, training_lookup, list_collections) — T-MA-013 ✅
- `yiacad_operator_index.sh` étendu : +7 actions (agents-status, agents-chat, agents-health, agents-e2e, studio-status, studio-files, studio-finetune) — T-MA-024 ✅
- `e2e_agents_test.sh` créé : 6 tests E2E (Sentinelle health+anomaly, Tower email, Forge quality, Devstral review, Handoff Sentinelle→Devstral) avec rapport JSON cockpit-v1 — T-MA-025 ✅
- `mistral_dataset_pipeline.py` créé : pipeline complète merge→validate→upload→finetune avec 3 domaines (kicad, spice-embedded, full), déduplication MD5, split train/val — Lot 24 T-MS-002/003 prêt
- `infra_container_health.sh` créé : health-check web+Docker avec fix/restart automatique pour containers down (metabase, listmonk, changedetection, bookmarks)
- Recherche web fine-tune Mistral 2026 : format ChatML JSONL confirmé, 200-5000 exemples min, loss only on assistant, Mistral Forge enterprise lancé
- Audit datasets existants : 12 fichiers JSONL (~176 MB total) dans mascarade-datasets/ — virtiofs deadlock empêche lecture directe, scripts VM-ready créés
- **Bilan session 4** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | Total 17/20 tâches complétées
- **Restant** : T-MA-016 (fine-tune KiCad), T-MA-017 (fine-tune SPICE), T-MA-021 (benchmark), T-MA-023 (docs Outline)
- **Session 5 — Cross-référence docs + Migration Beta API :**
- Capture documentation Mistral AI complète → `MISTRAL_DOCS_REFERENCE_2026-03-21.md` (469 lignes, 11 sections)
- Audit HuggingFace clemsail : 4 modèles LoRA (TinyLlama/Qwen), 8 datasets domaine
- **Découverte critique** : endpoint `/v1/agents/completions` marqué deprecated → Beta Conversations API disponible
- `mistral_agents_beta_api.py` créé (400+ lignes) :
- MistralBetaAgentsClient : chat(), chat_deprecated(), chat_with_fallback(), handoff(), health_check()
- MistralLibraryClient : create_library(), add_document(), list_documents() (RAG natif Mistral)
- Shortcuts nommés : sentinelle(), tower(), forge(), devstral()
- CLI complète : health, chat, chat-deprecated, handoff, libraries
- `e2e_agents_test.sh` mis à jour : support dual API (beta/deprecated), option --api-mode, fallback automatique
- T-MA-035 ✅, T-MA-036 ✅
- **Bilan session 5** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | P2bis 2/4 (50%) | Total 19/24 tâches
- **Restant** : T-MA-016/017 (fine-tune VM), T-MA-021 (benchmark), T-MA-023 (docs), T-MA-037/038 (migration TUI+provider)
- **Session 6 — Configuration AI Studio Agents v2 :**
- **4 agents configurés sur console.mistral.ai** (température + outils) :
- Sentinelle: temp 0.1, Code+Recherche activés → **v2 sauvé** ✅
- Tower: temp 0.4, Recherche+Image activés → **v2 sauvé** ✅
- Forge: temp 0.21, **pas de builtin tools** (codestral-latest ne supporte pas les connecteurs, Code 3004) → **v2 sauvé** ✅
- Devstral-Code: temp 0.17, **pas de builtin tools** (devstral-latest même limitation) → **v2 sauvé** ✅
- **Découverte** : `codestral-latest` et `devstral-latest` ne supportent pas les builtin connectors (Code, Image, Recherche, Recherche Premium) — erreur API 3004
- **Audit AI Studio complet** :
- Fichiers: 0 fichiers (prêt pour upload pipeline T-MS-002/003)
- Fine-tune > Modèles personnalisés: 0 modèles (en attente T-MS-010/011)
- Fine-tune > Jobs: 0 jobs
- Batches: 0 tâches par lot (en attente T-MS-012)
- IA Documentaire: OCR playground actif, 10 docs max, 50 Mo, PDF/images. API: 1000 pages/doc, 2000 pages/min
- Audio STT: Beta, offline+realtime, 10 fichiers, 1024 Mo, MP3/WAV/MP4/MOV/WEBM
- Vibe CLI: clé API active (***3Ltg), quota indisponible pour l'organisation
- Codestral: clé API active (***otEl), endpoints FIM+Chat confirmés
- **Bilan session 6** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | P2bis 2/4 (50%) | Total 19/24 tâches
- **Restant** : T-MA-016/017 (fine-tune VM), T-MA-021 (benchmark), T-MA-023 (docs), T-MA-037/038 (migration TUI+provider)
docs/plans/23_todo_integration_mistral_agents.md
+442
View File
@@ -0,0 +1,442 @@
# TODO 23 — Intégration Mistral Agents
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-21
> **Dernière MAJ**: 2026-03-22 (session 13 — runtime actif verrouillé sur le repo Mascarade)
> **Statut global**: 🟢 Phase 0 DONE — Phase 1 DONE — Phase 2 quasi-done (21/24) — Migration Beta API DONE — Agents AI Studio v2 configurés — OpenAI Platform ready — Anthropic Platform ready — Infra 3 providers opérationnelle
---
## 🔄 REPRISE PROCHAINE SESSION
**Contexte** : 8 sessions complétées. Infrastructure multi-LLM (Mistral + OpenAI) opérationnelle. Migration Beta API terminée.
**Tâches restantes Lot 23** (3/24 restantes) :
1. **T-MA-016** : Lancer fine-tune Mistral Small sur dataset KiCad fusionné (~15k examples) — nécessite VM avec accès mascarade-datasets/
- Config prête : `tools/mistral/finetune/configs/kicad_small.yaml`
- Script validation : `tools/mistral/finetune/prepare_and_validate.sh`
2. **T-MA-017** : Lancer fine-tune Codestral sur dataset SPICE+embedded (~20k examples) — idem VM
- Config prête : `tools/mistral/finetune/configs/spice_codestral.yaml`
3. **T-MA-021** : Benchmark comparatif base model vs fine-tuned sur 100 prompts métier — après fine-tune
- Framework prêt : `tools/evals/benchmark_providers.py` (3 providers, JSONL prompts, summary auto)
- 20 prompts template : `tools/evals/prompts/metier_100_template.jsonl` (à étendre à 100)
4. ~~**T-MA-023** : Documentation dans Outline wiki~~ — reporté Lot 24
5. ~~**T-MA-037** : Migrer `mistral_agents_tui.sh` vers Beta Conversations API~~ — ✅ session 8
6. ~~**T-MA-038** : Créer `mistral_agents.py` provider Mascarade (Beta API)~~ — ✅ session 8
**Infra prête** :
- Mistral AI Studio : 4 agents v2 (Sentinelle, Tower, Forge, Devstral) — IDs ci-dessous
- OpenAI Platform : 3 projets (Default, Mascarade, Kill_LIFE) + 3 clés API + 1 admin key — **$50 crédits**, auto-recharge ON
- Anthropic Platform : Org "L'électron rare" — 2 clés API (mascarade-router, kill-life-governance) — Evaluation access
- Pipeline fine-tune : `mistral_dataset_pipeline.py` prêt, 12 JSONL ~176 MB en attente upload
- Fine-tune configs : `tools/mistral/finetune/configs/` (kicad_small.yaml, spice_codestral.yaml)
- Benchmark framework : `tools/evals/benchmark_providers.py` (Mistral + Anthropic + OpenAI, 20 prompts template)
- Beta API client : `mistral_agents_beta_api.py` avec fallback deprecated
**Clés et IDs critiques** :
- Sentinelle: `ag_019d124c302375a8bf06f9ff8a99fb5f` (mistral-medium-latest, temp 0.1)
- Tower: `ag_019d124e760877359ad3ff5031179ebc` (magistral-medium-latest, temp 0.4)
- Forge: `ag_019d1251023f73258b80ac73f90458f6` (codestral-latest, temp 0.21)
- Devstral: `ag_019d125348eb77e880df33acbd395efa` (devstral-latest, temp 0.17)
- OpenAI Mascarade: `proj_Z6TszEfikDtBSfn5rIeaJnQI` — clé mascarade-router (sk-proj-...u5cA)
- OpenAI Kill_LIFE: `proj_CYBNMcd3L1ml9IZHC1tqdpQh` — clé kill-life-governance (sk-proj-...R78A)
- OpenAI Admin: clé "claude" (sk-admin-...uicA)
- Mistral mascarade-router: `708z...7kG` (workspace Default, expire jamais) — ✅ connectivité validée 22/03
- Mistral kill-life-governance: `14CW...f1b` (workspace Default, expire jamais)
- Mistral kxkm: `**...gJnw` (legacy, active, dernière utilisation 22 mars 2026)
- Mistral Billing: **Le Chat Team 59,98 €/mois** (2 sièges) + **AI Studio Scale** (pay-as-you-go, 6 RPS, 2M TPM, 10B tokens/mois, fine-tune inclus) — crédits API 0,00 € — Visa ****-2046
- Anthropic mascarade-router: `sk-ant-api03-bEo...hQAA` (workspace Default, Evaluation access) — ✅ validée
- Anthropic kill-life-governance: `sk-ant-api03-xKJ...zQAA` (workspace Default, Evaluation access) — ✅ validée
- Org Anthropic: "L'électron rare" — Plan: Evaluation access (free tier)
- Anthropic Rate Limits (Free Tier): 5 RPM, 10K input TPM, 4K output TPM par modèle (Sonnet/Opus/Haiku)
- Anthropic Batch: 5 RPM — Web Search: 30/s — Files Storage: 500 GB
- ⚠️ **Pas de crédits Anthropic** — nécessite achat crédits pour usage API
**Limitation connue** : codestral-latest et devstral-latest ne supportent PAS les builtin connectors AI Studio (Code, Image, Recherche) — erreur 3004
---
## P0 — Fondations (URGENT)
- [x] T-MA-001: Rédiger specs des 4 agents (Sentinelle, Tower, Forge, Devstral) → `MASTER_INTEGRATION_PLAN_2026-03-21.md`
- [x] T-MA-002: Créer `mistral_agents_tui.sh` dans tools/cockpit/
- [x] T-MA-003: Créer `integration_health_tui.sh` dans tools/cockpit/
- [x] T-MA-004: Créer les 4 agents sur console.mistral.ai/build/agents
- [x] Sentinelle (mistral-medium-latest, temp=0.1) → ag_019d124c302375a8bf06f9ff8a99fb5f
- [x] Tower (magistral-medium-latest, temp=0.4) → ag_019d124e760877359ad3ff5031179ebc
- [x] Forge (codestral-latest, temp=0.2) → ag_019d1251023f73258b80ac73f90458f6
- [x] Devstral (devstral-latest, temp=0.15) → ag_019d125348eb77e880df33acbd395efa
- [x] T-MA-005: Implémenter `mistral_agents_api.py` provider dans `core/mascarade/router/providers/`
- [x] T-MA-006: Ajouter config agents dans `mascarade/.env` (MISTRAL_AGENTS_API_KEY, agent IDs)
## P1 — Branchements
- [x] T-MA-010: Brancher Sentinelle → Mascarade API (/health, /providers, /metrics) → `sentinelle_connector.py`
- [x] T-MA-011: Brancher Sentinelle → Langfuse (traces, scores, latence) → `sentinelle_connector.py`
- [x] T-MA-012: Brancher Sentinelle → Grafana (Prometheus queries: CPU, RAM, disk) → `sentinelle_connector.py`
- [x] T-MA-013: Configurer Tower → Outline search (docs produit, formations) → `tower_outline_connector.py`
- [x] T-MA-014: Configurer Tower → template emails (premier contact, follow-up, proposal) → `tower_templates.py`
- [x] T-MA-015: Audit qualité des 10 datasets fine-tune → `dataset_audit_tui.sh` (cockpit)
- [ ] build_kicad_dataset.py
- [ ] build_spice_dataset.py
- [ ] build_freecad_dataset.py
- [ ] build_stm32_dataset.py
- [ ] build_embedded_dataset.py
- [ ] build_iot_dataset.py
- [ ] build_emc_dataset.py
- [ ] build_dsp_dataset.py
- [ ] build_power_dataset.py
- [ ] build_platformio_dataset.py
- [ ] T-MA-016: Lancer fine-tune Mistral Small sur dataset KiCad fusionné (~15k examples)
- [ ] T-MA-017: Lancer fine-tune Codestral sur dataset SPICE+embedded (~20k examples)
## P2 — Production & CI/CD
- [x] T-MA-020: Intégrer Devstral dans workflow CI → `devstral-review.yml` (GitHub Actions PR review)
- [ ] T-MA-021: Benchmark comparatif: base model vs fine-tuned sur 100 prompts métier
- [x] T-MA-022: Cron Sentinelle health-check (06:00 daily) → `sentinelle_cron.sh`
- [ ] T-MA-023: Documentation dans Outline wiki (4 pages: Sentinelle, Tower, Forge, Devstral)
- [x] T-MA-024: Intégrer `mistral_agents_tui.sh` dans `yiacad_operator_index.sh` → 7 new actions (agents-status/chat/health/e2e, studio-status/files/finetune)
- [x] T-MA-025: Tests d'intégration end-to-end (handoff Sentinelle → Devstral → fix auto) → `e2e_agents_test.sh`
## P2bis — Migration API (CRITIQUE)
- [x] T-MA-035: Créer `mistral_agents_beta_api.py` — client Beta Conversations API avec fallback deprecated
- [x] MistralBetaAgentsClient: chat(), chat_deprecated(), chat_with_fallback()
- [x] Pattern Handoff intégré (handoff from→to)
- [x] MistralLibraryClient pour Document Library RAG (Tower)
- [x] Health check avec ping de tous les agents
- [x] CLI test (health, chat, handoff, libraries)
- [x] T-MA-036: Mettre à jour `e2e_agents_test.sh` — support Beta API + fallback deprecated
- [x] call_agent() refactoré avec _call_api() → conversations/completions puis agents/completions
- [x] Option --api-mode (beta|deprecated)
- [x] Rapport JSON inclut api_mode
- [x] T-MA-037: Migrer `mistral_agents_tui.sh` vers Beta Conversations API
- [x] Rewrite complet: API abstraction layer (_call_beta, _call_deprecated, call_agent)
- [x] Fallback automatique beta → deprecated
- [x] Nouvelle action handoff (Sentinelle→Devstral)
- [x] API mode toggle (beta/deprecated)
- [x] extract_content() compatible deux formats de réponse
- [x] T-MA-038: Créer `mistral_agents.py` provider Mascarade (Beta Conversations API)
- [x] Provider dédié `MistralAgentsProvider` dans providers/mistral_agents.py
- [x] Registre des 4 agents avec IDs, modèles, températures, rôles
- [x] send() avec fallback beta → deprecated
- [x] send_to_agent() API haut niveau pour workflows
- [x] handoff() inter-agents (from→to avec transform_prompt)
- [x] Enregistré dans providers/__init__.py
- [x] Config `mistral_agents_api_mode` ajoutée dans config.py
## P3 — Évolutions futures
- [ ] T-MA-030: Implémenter A2A protocol dans Mascarade (MCP + A2A complémentaires)
- [ ] T-MA-031: Migrer orchestrateur Mascarade vers graph-based state (LangGraph-compatible)
- [ ] T-MA-032: Ajouter RAG Document Library à Tower (Outline + docs PDF) — via MistralLibraryClient
- [ ] T-MA-033: Pipeline d'évaluation continue des agents (weekly benchmark)
- [ ] T-MA-034: Étendre lot_chain.sh avec dispatch vers agents Mistral
---
## Journal de bord
### 2026-03-21
- Création du lot 23
- Specs des 4 agents rédigées dans MASTER_INTEGRATION_PLAN
- TUI `mistral_agents_tui.sh` et `integration_health_tui.sh` déployés dans cockpit
- Recherche web effectuée : Mistral Agents API, MCP 2026, LangGraph 2026
- Matrice agent × tâche établie avec dépendances critiques
- **4 agents créés sur console.mistral.ai** avec IDs réels :
- Sentinelle: ag_019d124c302375a8bf06f9ff8a99fb5f (mistral-medium, temp 0.1)
- Tower: ag_019d124e760877359ad3ff5031179ebc (magistral-medium, temp 0.4)
- Forge: ag_019d1251023f73258b80ac73f90458f6 (codestral, temp 0.2)
- Devstral-Code: ag_019d125348eb77e880df33acbd395efa (devstral, temp 0.15)
- `mistral_agents_api.py` provider implémenté et mis à jour avec les 4 IDs
- Note: mistral-large indisponible dans agents → Tower utilise magistral-medium (meilleur raisonnement dispo)
- **Session 2 — Phase 1 :**
- `sentinelle_connector.py` créé : 7 tools MCP (mascarade_health, mascarade_providers, mascarade_metrics, langfuse_traces, langfuse_scores, prometheus queries, full_diagnostic)
- `tower_templates.py` créé : 7 templates emails (premier_contact_inbound/outbound, followup_post_demo, proposition_commerciale, formation_kicad, relance_30j/60j)
- `dataset_audit_tui.sh` créé : audit statique des 10 builders (score/8, couverture, validation, dedup, balance)
- `test_mistral_agents_provider.py` créé : 20+ tests unitaires (registry, provider, complete, handoff, health_check, singleton) + tests d'intégration
- `.env.example` mis à jour avec les 4 agent IDs
- Note: virtiofs EDEADLK deadlock persiste sur fichiers existants du repo — nouveaux fichiers OK
- `devstral-review.yml` créé : GitHub Actions workflow pour code review automatique par Devstral sur PRs
- `sentinelle_cron.sh` créé : cron daily health-check avec analyse Sentinelle + alerting webhook
- **Bilan session 2** : P0 6/6 ✅ | P1 5/8 (63%) | P2 2/6 (33%) | Total 13/20 tâches complétées
- **Session 3 — Analyse exhaustive + Lot 24 :**
- Exploration complète Mistral AI Studio (Playground, Agents, Batches, IA Documentaire, Audio offline+realtime, Fine-tune Modèles+Jobs, Fichiers, Vibe CLI, Codestral)
- Analyse exhaustive Kill_LIFE (47 scripts, 22 plans, 6 agents BMAD, 15+ schemas JSON)
- Analyse exhaustive Mascarade (10+ providers, 15+ services Docker, 10 builders fine-tune)
- Recherche web état de l'art 2026 (MCP, A2A, LangGraph, n8n, fine-tune ORPO/KTO, frameworks agentiques)
- Document `ANALYSE_EXHAUSTIVE_ECOSYSTEME_2026-03-21.md` généré (diagrammes Mermaid, feature maps, matrice agents)
- `mistral_studio_tui.sh` créé (14 actions couvrant toute la console Mistral Studio)
- Lot 24 plan + TODO créés (16 tâches, 4 phases: Fichiers, Fine-tune, Intégrations Studio, Production)
- **Chaînage** : Lot 23 → Lot 24 (Intégration Mistral Studio Complète)
- **Session 4 — Exécution Lot 23 restant + Pipeline Lot 24 :**
- `tower_outline_connector.py` créé : OutlineConnector (sync+async) avec 5 MCP tools (search, get_document, product_lookup, training_lookup, list_collections) — T-MA-013 ✅
- `yiacad_operator_index.sh` étendu : +7 actions (agents-status, agents-chat, agents-health, agents-e2e, studio-status, studio-files, studio-finetune) — T-MA-024 ✅
- `e2e_agents_test.sh` créé : 6 tests E2E (Sentinelle health+anomaly, Tower email, Forge quality, Devstral review, Handoff Sentinelle→Devstral) avec rapport JSON cockpit-v1 — T-MA-025 ✅
- `mistral_dataset_pipeline.py` créé : pipeline complète merge→validate→upload→finetune avec 3 domaines (kicad, spice-embedded, full), déduplication MD5, split train/val — Lot 24 T-MS-002/003 prêt
- `infra_container_health.sh` créé : health-check web+Docker avec fix/restart automatique pour containers down (metabase, listmonk, changedetection, bookmarks)
- Recherche web fine-tune Mistral 2026 : format ChatML JSONL confirmé, 200-5000 exemples min, loss only on assistant, Mistral Forge enterprise lancé
- Audit datasets existants : 12 fichiers JSONL (~176 MB total) dans mascarade-datasets/ — virtiofs deadlock empêche lecture directe, scripts VM-ready créés
- **Bilan session 4** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | Total 17/20 tâches complétées
- **Restant** : T-MA-016 (fine-tune KiCad), T-MA-017 (fine-tune SPICE), T-MA-021 (benchmark), T-MA-023 (docs Outline)
- **Session 5 — Cross-référence docs + Migration Beta API :**
- Capture documentation Mistral AI complète → `MISTRAL_DOCS_REFERENCE_2026-03-21.md` (469 lignes, 11 sections)
- Audit HuggingFace clemsail : 4 modèles LoRA (TinyLlama/Qwen), 8 datasets domaine
- **Découverte critique** : endpoint `/v1/agents/completions` marqué deprecated → Beta Conversations API disponible
- `mistral_agents_beta_api.py` créé (400+ lignes) :
- MistralBetaAgentsClient : chat(), chat_deprecated(), chat_with_fallback(), handoff(), health_check()
- MistralLibraryClient : create_library(), add_document(), list_documents() (RAG natif Mistral)
- Shortcuts nommés : sentinelle(), tower(), forge(), devstral()
- CLI complète : health, chat, chat-deprecated, handoff, libraries
- `e2e_agents_test.sh` mis à jour : support dual API (beta/deprecated), option --api-mode, fallback automatique
- T-MA-035 ✅, T-MA-036 ✅
- **Bilan session 5** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | P2bis 2/4 (50%) | Total 19/24 tâches
- **Restant** : T-MA-016/017 (fine-tune VM), T-MA-021 (benchmark), T-MA-023 (docs), T-MA-037/038 (migration TUI+provider)
- **Session 6 — Configuration AI Studio Agents v2 :**
- **4 agents configurés sur console.mistral.ai** (température + outils) :
- Sentinelle: temp 0.1, Code+Recherche activés → **v2 sauvé** ✅
- Tower: temp 0.4, Recherche+Image activés → **v2 sauvé** ✅
- Forge: temp 0.21, **pas de builtin tools** (codestral-latest ne supporte pas les connecteurs, Code 3004) → **v2 sauvé** ✅
- Devstral-Code: temp 0.17, **pas de builtin tools** (devstral-latest même limitation) → **v2 sauvé** ✅
- **Découverte** : `codestral-latest` et `devstral-latest` ne supportent pas les builtin connectors (Code, Image, Recherche, Recherche Premium) — erreur API 3004
- **Audit AI Studio complet** :
- Fichiers: 0 fichiers (prêt pour upload pipeline T-MS-002/003)
- Fine-tune > Modèles personnalisés: 0 modèles (en attente T-MS-010/011)
- Fine-tune > Jobs: 0 jobs
- Batches: 0 tâches par lot (en attente T-MS-012)
- IA Documentaire: OCR playground actif, 10 docs max, 50 Mo, PDF/images. API: 1000 pages/doc, 2000 pages/min
- Audio STT: Beta, offline+realtime, 10 fichiers, 1024 Mo, MP3/WAV/MP4/MOV/WEBM
- Vibe CLI: clé API active (***3Ltg), quota indisponible pour l'organisation
- Codestral: clé API active (***otEl), endpoints FIM+Chat confirmés
- **Bilan session 6** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | P2bis 2/4 (50%) | Total 19/24 tâches
- **Restant** : T-MA-016/017 (fine-tune VM), T-MA-021 (benchmark), T-MA-023 (docs), T-MA-037/038 (migration TUI+provider)
- **Session 7 — Configuration OpenAI Platform :**
- **OpenAI Platform** configuré comme provider complémentaire Mascarade :
- Billing: $50 credit, auto-recharge ON ($25 @ $15 threshold), pay-as-you-go
- Admin key "claude" (sk-admin-...uicA): Active, All permissions — administration globale
- Assistants API: deprecated (suppression août 2026) → utiliser Responses API
- **3 projets créés** pour isolation API :
- Default project: `proj_OwtOT7Ws1BtPVsKFkuI3VFpM` (12 fév. 2026)
- Mascarade: `proj_Z6TszEfikDtBSfn5rIeaJnQI` (22 mars 2026)
- Kill_LIFE: `proj_CYBNMcd3L1ml9IZHC1tqdpQh` (22 mars 2026)
- **2 clés API projet créées** :
- mascarade-router (sk-proj-UTp...EV9JL9...) → projet Mascarade, All permissions
- kill-life-governance (sk-proj-xiO...x92WpF75l...) → projet Kill_LIFE, All permissions
- **Architecture multi-provider OpenAI** : projets isolés permettent suivi usage/coûts par écosystème
- **Bilan session 7** : P0 6/6 ✅ | P1 7/8 (88%) | P2 4/6 (67%) | P2bis 2/4 (50%) | OpenAI Platform ✅ | Total 19/24 tâches Mistral + infra OpenAI ready
- **Restant** : T-MA-016/017 (fine-tune VM), T-MA-021 (benchmark), T-MA-023 (docs), T-MA-037/038 (migration TUI+provider)
### 2026-03-22 (session 8)
- **T-MA-037 DONE** : `mistral_agents_tui.sh` entièrement réécrit pour Beta Conversations API
- API abstraction layer : `_call_beta()` (POST /v1/conversations) + `_call_deprecated()` (POST /v1/agents/{id}/completions)
- `call_agent()` unifié avec fallback automatique beta → deprecated
- `extract_content()` compatible deux formats (outputs/choices)
- Nouvelle action `handoff` (Sentinelle diagnostique → Devstral corrige)
- Menu v2 avec toggle API mode beta/deprecated
- **T-MA-038 DONE** : `mistral_agents.py` créé dans `mascarade/router/providers/`
- `MistralAgentsProvider` : provider dédié aux 4 agents Mistral AI Studio
- Registre agents : Sentinelle, Tower, Forge, Devstral (IDs, modèles, températures, rôles)
- `send()` conforme interface LLMProvider avec résolution agent par nom/ID
- `send_to_agent()` : API haut niveau pour appels directs par nom d'agent
- `handoff()` : workflow inter-agents (from→to avec injection contexte)
- `stream()` : fallback vers send() (Conversations API ne supporte pas le streaming)
- Enregistré dans `providers/__init__.py`, config `mistral_agents_api_mode` ajoutée
- **Bilan session 8** : P0 6/6 ✅ | P1 7/8 (88%) | P2 6/6 ✅ | P2bis 4/4 ✅ | Total 21/24 — Migration Beta API terminée
- **Clés API Mistral AI Studio créées** :
- mascarade-router: `**...5Gav` (workspace Default, expire jamais)
- kill-life-governance: `**...4Gid` (workspace Default, expire jamais)
- **GitHub Ecosystem Map** : `github_ecosystem_map.md` créé dans docs/references/
- Cartographie complète : Anthropic (77 repos), OpenAI (234 repos), Mistral (24 repos)
- SDKs, agents, tools, comparatifs CLI/frameworks, mapping providers→repos
- **Anthropic Claude Platform** configuré :
- Org: "L'électron rare" — Plan: Evaluation access (free tier)
- Clé mascarade-router: `sk-ant-api03-Fj1...dwAA` (workspace Default)
- Clé kill-life-governance: `sk-ant-api03-xKJ...zQAA` (workspace Default)
- Rate Limits Free Tier: 5 RPM, 10K input TPM, 4K output TPM (Sonnet/Opus/Haiku)
- ⚠️ Pas de crédits — nécessite achat pour usage API
- **OpenAI Platform** vérifié : $50 crédits actifs, auto-recharge ON, 3 projets confirmés
- **Bilan session 8 final** : Infrastructure multi-LLM 3 providers (Mistral + OpenAI + Anthropic) opérationnelle
- **Restant** : T-MA-016/017 (fine-tune, nécessite VM), T-MA-021 (benchmark, nécessite fine-tune)
---
## Session 9 — 2026-03-22 — Hardening local Beta API / reprise cockpit
Travail local ferme sans dependance VM fine-tune.
Fait:
- hardening de `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/e2e_agents_test.sh`
- payload Beta Conversations aligne sur `/v1/conversations`
- fallback deprecated aligne sur `/v1/agents/{id}/completions`
- parsing assistant robuste sur `outputs[].content` et `choices[].message.content`
- logs internes envoyes sur stderr pour ne plus polluer les JSON captures
- hardening de `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/sentinelle_cron.sh`
- migration Beta API avec fallback deprecated
- ajout du reporting `analysis_api_mode`
- ecriture JSON du rapport rendue plus sure
- hardening du bridge Mascarade sur la structure reelle du repo:
- `/Users/electron/Documents/Projets/mascarade/core/mascarade/agents/mistral_agents.py`
- normalisation des blocs `outputs[].content` en texte simple
Constat topologie:
- repo Mascarade de reference pour ce lot: `/Users/electron/Documents/Projets/mascarade`
- ne pas utiliser la copie `Github_Repos/Perso/mascarade-main` pour ces correctifs
- le chemin historique `core/mascarade/router/providers/mistral_agents.py` n'est pas la structure active ici
Reste ouvert inchangé:
- `T-MA-016` fine-tune KiCad merge ~15k -> VM / datasets requis
- `T-MA-017` fine-tune Codestral SPICE+embedded ~20k -> VM / datasets requis
- `T-MA-021` benchmark base vs fine-tuned sur 100 prompts -> apres fine-tune
- `T-MA-023` docs Outline -> reporte Lot 24
## Gouvernance de dossier — source de verite unique
Decision verrouillee a partir du 2026-03-22.
Dossiers autorises:
- Kill_LIFE tracking / cockpit: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE`
- Mascarade code actif: `/Users/electron/Documents/Projets/mascarade`
Dossier interdit pour ce lot:
- `/Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/mascarade-main`
Regle operative:
- tout correctif Mascarade Mistral doit etre applique uniquement dans `/Users/electron/Documents/Projets/mascarade`
- tout suivi, journal de session, TODO et scripts cockpit restent uniquement dans `Kill_LIFE`
- ne pas melanger les deux copies ni reporter des chemins obsoletes dans les prochaines sessions
Chemins actifs de reference pour Mistral:
- provider standard: `/Users/electron/Documents/Projets/mascarade/core/mascarade/router/providers/mistral.py`
- agents distants Mistral: `/Users/electron/Documents/Projets/mascarade/core/mascarade/agents/mistral_agents.py`
- router API Mistral agents: `/Users/electron/Documents/Projets/mascarade/core/mascarade/routers/mistral_agents.py`
Garde-fou operateur ajoute:
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/mistral_workspace_guard.sh`
- usage: `bash tools/cockpit/mistral_workspace_guard.sh --action status --json`
- objectif: signaler toute derive de dossier et rappeler la source de verite unique
## Session 10 — 2026-03-22 — Preflight dataset local avant lots VM
Travail local uniquement dans `Kill_LIFE`.
Fait:
- refonte de `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/dataset_audit_tui.sh`
- le script couvre maintenant trois actions explicites:
- `--action audit`
- `--action preflight`
- `--action paths`
- le script rappelle la source de verite Mascarade active: `/Users/electron/Documents/Projets/mascarade`
- le script expose dans le JSON cockpit:
- readiness locale
- chemins canoniques
- presence de copie interdite
- lots bloques cote VM: `T-MS-002`, `T-MS-003`, `T-MA-016`, `T-MA-017`, `T-MA-021`
Lecture operationnelle:
- `T-MA-015` devient la surface locale de preflight dataset
- la suite reste dependante du host VM dataset/fine-tune (`photon-docker` par defaut)
- pas de confusion entre audit local et execution VM
## Session 11 — 2026-03-22 — Re-synchronisation provider dans le repo actif
Travail applique uniquement dans:
- `/Users/electron/Documents/Projets/mascarade`
Fait:
- `T-MA-038` re-synchronise dans le repo actif, sans reutiliser la copie interdite `mascarade-main`
- provider ajoute et branche dans le routeur actif:
- `/Users/electron/Documents/Projets/mascarade/core/mascarade/router/providers/mistral_agents.py`
- `/Users/electron/Documents/Projets/mascarade/core/mascarade/router/providers/__init__.py`
- `/Users/electron/Documents/Projets/mascarade/core/mascarade/router/router.py`
- bridge d'agents distants durci:
- `/Users/electron/Documents/Projets/mascarade/core/mascarade/agents/mistral_agents.py`
- base URL configurable
- fallback beta conversations -> deprecated completions
- IDs d'agents lus depuis la config active
- tests locaux ajoutes / ajustes:
- `/Users/electron/Documents/Projets/mascarade/core/tests/test_mistral_agents.py`
- `/Users/electron/Documents/Projets/mascarade/core/tests/test_mistral_agents_provider.py`
- validation locale passee:
- `cd /Users/electron/Documents/Projets/mascarade/core && ./.venv/bin/python -m py_compile mascarade/config.py mascarade/agents/mistral_agents.py mascarade/router/providers/__init__.py mascarade/router/providers/mistral_agents.py mascarade/router/router.py tests/test_mistral_agents.py tests/test_mistral_agents_provider.py`
- `cd /Users/electron/Documents/Projets/mascarade/core && ./.venv/bin/python -m pytest tests/test_mistral_agents.py tests/test_mistral_agents_provider.py tests/test_router.py -q`
Constat:
- le tracking session 8 disait `T-MA-038` termine, mais le repo actif n'avait pas encore le provider routeur branche
- l'etat est maintenant aligne entre tracking et code actif pour `T-MA-038`
Reste ouvert inchangé:
- `T-MA-016`, `T-MA-017`, `T-MA-021` toujours bloques cote VM / datasets / fine-tune
- `T-MA-023` reste reporte lot 24
## Session 11 — 2026-03-22 — Cartographie mesh Mascarade et sync .env
Travail local uniquement dans `Kill_LIFE`.
Fait:
- ajout de `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/mascarade_mesh_env_sync.sh`
- le script fige les racines Mascarade canoniques par machine:
- `clems@192.168.0.120` -> `/home/clems/mascarade`
- `root@192.168.0.119` -> `/root/mascarade-main`
- `kxkm@kxkm-ai` -> `/home/kxkm/mascarade`
- `cils@100.126.225.111` -> `/Users/cils/mascarade-main`
- correction de l'hypothese fausse sur `cils`:
- ce n'est pas un layout Linux `/home/cils/*`
- le bon layout actif est macOS `/Users/cils/*`
- propagation `.env` refaite avec succes sur les 4 cibles via le script
Artefact de reference:
- `artifacts/cockpit/mascarade_mesh_env_sync/latest.json`
Lecture operationnelle:
- les prochains lots Mistral ne doivent plus re-decouvrir les racines Mascarade sur ces 4 machines
- utiliser `mascarade_mesh_env_sync.sh` comme source de verite operateur pour la sync d'environnement
## Session 12 — 2026-03-22 — Separation des cles Mistral router / governance
Travail local uniquement dans `Kill_LIFE`, sans modifier la convention provider Mascarade.
Decision retenue:
- `Mascarade` continue d'utiliser `MISTRAL_API_KEY` comme cle routeur
- `Kill_LIFE` utilise desormais `MISTRAL_GOVERNANCE_API_KEY` pour les scripts de gouvernance quand elle est presente
- fallback conserve: si `MISTRAL_GOVERNANCE_API_KEY` est absente, les scripts `Kill_LIFE` retombent sur `MISTRAL_API_KEY`
Fait:
- ajout de `tools/cockpit/load_mistral_governance_env.sh`
- ajout de `tools/cockpit/kill_life_mistral_governance_sync.sh`
- `e2e_agents_test.sh` charge maintenant la cle gouvernance si disponible
- `sentinelle_cron.sh` charge maintenant la cle gouvernance si disponible
- `tools/mistral/mistral_client.py` lit `MISTRAL_GOVERNANCE_API_KEY` puis fallback `MISTRAL_API_KEY`, puis fallback secret file local
- secret local hors repo cree et synchronise:
- local -> `~/.kill-life/mistral.env`
- clems -> `/home/clems/.kill-life/mistral.env`
- root -> `/root/.kill-life/mistral.env`
- kxkm -> `/home/kxkm/.kill-life/mistral.env`
- cils -> `/Users/cils/.kill-life/mistral.env`
Artefact de reference:
- `artifacts/cockpit/kill_life_mistral_governance_sync/latest.json`
Point volontairement non fait:
- aucune seconde variable Mistral n'a ete ajoutee au code Mascarade
- le routeur Mascarade reste sur la seule variable canonique `MISTRAL_API_KEY`
## Session 13 — 2026-03-22 — Separation cockpit direct / runtime provider
Travail applique uniquement dans:
- `/Users/electron/Documents/Projets/mascarade`
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE`
Decision retenue:
- `Kill_LIFE` cockpit operateur reste en appels directs Mistral Studio
- le runtime Mascarade appelle les agents distants via le provider `mistral-agents`
- le repo historique `mascarade-main` reste interdit comme cible d'edition
Fait:
- mapping d'env `MISTRAL_AGENTS_API_MODE` + `MISTRAL_AGENT_*_ID` consolide dans `docs/MISTRAL_STUDIO_INTEGRATION.md`
- aucun secret ni ID reel supplementaire recopie dans le repo actif
- `T-MA-038` confirme comme implementation runtime canonique dans `/Users/electron/Documents/Projets/mascarade`
Impact:
- le tracking lot 23 reste aligne avec le code actif
- la separation cockpit/runtime est maintenant explicite pour les prochaines vagues Studio
docs/plans/23_todo_yiacad_git_eda_platform.md
+16
View File
@@ -0,0 +1,16 @@
# Todo 23 - YiACAD Git EDA platform
- [x] Create `web/` scaffold for Next.js + GraphQL + Yjs transport
- [x] Store `.excalidraw` diagrams as Git-tracked JSON under `web/project/diagrams`
- [x] Expose product routes for dashboard, diagram editor, PCB viewer, and PR review
- [x] Add local GraphQL gateway with project, diagram, CI, artifact, and PR review data
- [x] Add dedicated realtime server launcher for Yjs websocket transport
- [x] Install `web/` dependencies and produce a successful first `next build`
- [x] Vendor the official KiCanvas bundle into `web/public/vendor/kicanvas.js`
- [x] Replace the JSON queue stub with a Redis-backed queue contract via `BullMQ`
- [x] Add a real EDA worker entry wired to KiCad headless, STEP export, KiBot fallback, and KiAuto hooks
- [x] Fold `plan 23` into the intelligence lane and assign dedicated owners for `web/*`, realtime, and workers
- [ ] Bind Excalidraw scene updates into Yjs room state
- [x] Replace PR/artifact placeholder JSON with real Git and CI derived state
- [ ] Surface worker, queue, and realtime health into the intelligence memory and runtime gateway
- [ ] Add a first read-only review-assist surface backed by changed files, ERC/DRC outputs, and ops summary
docs/plans/24_plan_integration_mistral_studio.md
+71
View File
@@ -0,0 +1,71 @@
# Plan 24 — Intégration Mistral AI Studio Complète
> **Owner**: PM-Mesh + Architect + Forge
> **Date**: 2026-03-21
> **Statut**: 🟢 Lancé
> **Dépendances**: Lot 23 (agents créés ✅)
---
## Contexte
Suite au Lot 23 (agents Mistral créés + provider), ce lot couvre l'intégration
de **toutes les fonctionnalités** de Mistral AI Studio dans l'écosystème :
Fichiers, Fine-tune, Batches, IA Documentaire, Audio, Vibe CLI, Codestral.
## Phases
### P0 — Fichiers & Datasets (J1-J2)
| # | Tâche | Agent | Livrable | Status |
|---|-------|-------|---------|--------|
| 1 | Créer `mistral_studio_tui.sh` cockpit | Doc + PM | Script TUI | [x] |
| 2 | Upload datasets fine-tune via API Files | Forge | 10 JSONL Mistral | [ ] |
| 3 | Upload docs RAG pour Tower | Tower + Doc | Document Library | [ ] |
| 4 | Upload datasheets composants pour OCR | HW + Sentinelle | Pipeline OCR | [ ] |
### P1 — Fine-tune & Batches (J3-J7)
| # | Tâche | Agent | Livrable | Status |
|---|-------|-------|---------|--------|
| 5 | Fine-tune KiCad sur Mistral Small | Forge + HW | ft:kicad-v1 | [ ] |
| 6 | Fine-tune SPICE+Embedded sur Codestral | Forge + FW | ft:spice-embedded-v1 | [ ] |
| 7 | Batch benchmark base vs fine-tuned (100 prompts) | QA + Forge | Rapport comparatif | [ ] |
| 8 | Configurer Document Library RAG pour Tower | Tower | Recherche docs active | [ ] |
### P2 — Intégrations Studio (J8-J10)
| # | Tâche | Agent | Livrable | Status |
|---|-------|-------|---------|--------|
| 9 | Intégrer IA Documentaire dans pipeline OCR | Sentinelle + HW | OCR automatisé | [ ] |
| 10 | Intégrer Audio STT dans ops workflow | Sentinelle | Transcription auto | [ ] |
| 11 | Installer Vibe CLI sur VM photon-docker | Devstral | CLI opérationnel | [ ] |
| 12 | Intégrer Codestral FIM dans Mascarade | Architect + Devstral | Provider FIM | [ ] |
### P3 — Production (J11-J14)
| # | Tâche | Agent | Livrable | Status |
|---|-------|-------|---------|--------|
| 13 | Déployer modèles fine-tuned dans Mascarade | Architect | Router mis à jour | [ ] |
| 14 | Tests E2E pipeline Studio→Mascarade→Agent | QA | Evidence pack | [ ] |
| 15 | Documentation Outline (4 pages Studio) | Doc | Wiki à jour | [ ] |
| 16 | Cron audit qualité modèles (weekly) | QA + Sentinelle | Benchmark continu | [ ] |
---
## Risques
| Risque | Impact | Mitigation |
|--------|--------|-----------|
| Datasets insuffisants (<5k exemples) | Fine-tune dégradé | Augmentation via prompting + OSS |
| Coût fine-tune élevé | Budget | Commencer par Mistral Small (moins cher) |
| Playground nécessite plan payant | Tests limités | Utiliser API directement via TUI |
| virtiofs deadlock | Code illisible | Audit sur VM directement |
## Critères de succès
- [ ] 2 modèles fine-tuned déployés dans Mascarade
- [ ] Benchmark >15% amélioration sur prompts métier
- [ ] IA Documentaire OCR fonctionnel sur datasheets
- [ ] Audio STT intégré dans workflow ops
- [ ] Vibe CLI opérationnel sur VM
docs/plans/24_todo_integration_mistral_studio.md
+239
View File
@@ -0,0 +1,239 @@
# TODO 24 — Intégration Mistral AI Studio Complète
> **Owner**: PM-Mesh + Architect + Forge
> **Date création**: 2026-03-21
> **Dernière MAJ**: 2026-03-22 (session 9 — Codestral FIM intégré sur la base active)
> **Statut global**: 🟢 Phase 0 en cours — Pipeline dataset prête — Docs reference compilée — Audit Studio complet — OpenAI Platform ready
---
## 🔄 REPRISE PROCHAINE SESSION
**Contexte** : Lot 24 en Phase 0, seul T-MS-001 complété. Pipeline `mistral_dataset_pipeline.py` prête mais nécessite VM avec accès datasets.
**Prochaines actions prioritaires** :
1. **T-MS-002/003** : Merger + valider + upload datasets KiCad et SPICE+Embedded via pipeline
2. **T-MS-010/011** : Lancer fine-tune jobs une fois datasets uploadés
3. **T-MS-004** : Upload docs commerciales pour Tower Document Library
4. ~~**T-MS-023** : Intégrer Codestral FIM dans Mascarade router~~ — ✅ clôturé sur le provider `codestral` existant dans le repo actif
**Dépendances** :
- T-MS-002/003 → nécessite VM photon-docker avec accès mascarade-datasets/ (12 JSONL, ~176 MB)
- T-MS-010/011 → nécessite datasets uploadés (T-MS-002/003)
- T-MS-012 → nécessite modèles fine-tuned (T-MS-010/011)
**Outils prêts** :
- `mistral_dataset_pipeline.py` : merge, validate, upload, finetune
- `mistral_studio_tui.sh` : 14 actions cockpit
- `mistral_agents_beta_api.py` : client Beta API avec MistralLibraryClient
- OpenAI Platform : projets Mascarade + Kill_LIFE avec clés API dédiées
- Anthropic Platform : Org "L'électron rare" — clés mascarade-router + kill-life-governance — Evaluation access
---
## P0 — Fichiers & Datasets
- [x] T-MS-001: Créer `mistral_studio_tui.sh` cockpit (Agents, Files, Fine-tune, Batches, OCR, Audio, Codestral)
- [ ] T-MS-002: Préparer dataset KiCad JSONL (format ChatML, >5k exemples)
- [ ] Merger build_kicad_dataset.py outputs
- [ ] Valider format avec `training/scripts/validate_dataset.py`
- [ ] Upload via `mistral_studio_tui.sh --files-upload`
- [ ] T-MS-003: Préparer dataset SPICE+Embedded JSONL
- [ ] Merger build_spice_dataset.py + build_embedded_dataset.py + build_stm32_dataset.py
- [ ] Valider et upload
- [ ] T-MS-004: Upload docs commerciales pour Tower Document Library
- [ ] Exporter docs Outline (formations, produits)
- [ ] Upload via Files API
- [ ] T-MS-005: Upload 5 datasheets composants test pour IA Documentaire
- [ ] Sélectionner datasheets PDF (STM32, ESP32, composants courants)
- [ ] Tester OCR via `mistral_studio_tui.sh --ocr`
## P1 — Fine-tune
- [ ] T-MS-010: Lancer fine-tune KiCad sur `open-mistral-7b`
- [ ] Configurer hyperparamètres (100 steps, lr=1e-5)
- [ ] Monitorer via `mistral_studio_tui.sh --finetune-list`
- [ ] Valider modèle `ft:kicad-v1`
- [ ] T-MS-011: Lancer fine-tune SPICE+Embedded sur `codestral-latest`
- [ ] Upload dataset fusionné
- [ ] Configurer et lancer job
- [ ] Valider modèle `ft:spice-embedded-v1`
- [ ] T-MS-012: Batch benchmark 100 prompts métier
- [ ] Créer fichier JSONL 100 prompts (20 KiCad, 20 SPICE, 20 embedded, 20 IoT, 20 mixed)
- [ ] Exécuter batch sur modèle base
- [ ] Exécuter batch sur modèle fine-tuned
- [ ] Comparer résultats (scoring automatique + review)
- [ ] T-MS-013: Configurer Document Library RAG Tower
- [ ] Associer docs uploadés à agent Tower
- [ ] Tester queries de recherche
- [ ] Valider scoring leads avec contexte RAG
## P2 — Intégrations Studio
- [ ] T-MS-020: Pipeline OCR datasheets via IA Documentaire
- [ ] Script batch OCR (traitement dossier complet)
- [ ] Extraction specs composants → JSON structuré
- [ ] Intégrer dans knowledge base Sentinelle
- [ ] T-MS-021: Audio STT dans workflow ops
- [ ] Script transcription réunions (offline batch)
- [ ] Intégrer dans intelligence_tui.sh
- [ ] Action items extraction post-transcription
- [ ] T-MS-022: Installer Vibe CLI sur VM photon-docker
- [ ] `curl -LsSf https://mistral.ai/vibe/install.sh | bash`
- [ ] `vibe --setup` avec clé API
- [ ] Tester interactions Forge/Devstral
- [x] T-MS-023: Intégrer Codestral FIM dans Mascarade
- [x] Pas de `codestral_fim.py` séparé ; extension du provider `codestral.py` existant
- [x] Endpoint Mistral utilisé: `https://codestral.mistral.ai/v1/fim/completions`
- [x] Exposition runtime: `/v1/api/providers/codestral/fim` + façade `/api/providers/codestral/fim`
- [x] Tests ciblés de complétion code embarqué / complétion structurée
## P3 — Production
- [ ] T-MS-030: Déployer modèles fine-tuned dans Mascarade router
- [ ] Ajouter `ft:kicad-v1` et `ft:spice-embedded-v1` comme providers
- [ ] Configurer routing par domaine
- [ ] T-MS-031: Tests E2E Studio→Mascarade→Agent
- [ ] Scénario 1: Upload datasheet → OCR → Sentinelle analyse
- [ ] Scénario 2: Prompt KiCad → Router → ft:kicad-v1 → réponse
- [ ] Scénario 3: Audio meeting → STT → action items → Tower email
- [ ] T-MS-032: Documentation Outline wiki
- [ ] Page: Mistral Studio Overview
- [ ] Page: Fine-tune Pipeline Guide
- [ ] Page: IA Documentaire Usage
- [ ] Page: Audio Integration
- [ ] T-MS-033: Cron audit qualité modèles (weekly via Sentinelle)
- [ ] 10 prompts test par modèle
- [ ] Scoring automatique
- [ ] Alerte si dégradation >5%
---
## Journal de bord
### 2026-03-21
- Création du lot 24
- Analyse exhaustive de toutes les options Mistral AI Studio
- `mistral_studio_tui.sh` créé (14 actions: agents, files, finetune, batches, OCR, audio, codestral, logs)
- Cartographie complète: Playground, Agents, Batches, IA Documentaire, Audio (offline+realtime), Fine-tune (Modèles+Jobs), Fichiers, Vibe CLI, Codestral
- État actuel: 1 clé API active, 4 agents créés, 0 fichiers, 0 jobs fine-tune, 0 batches
- Endpoints Codestral documentés: FIM completions + Chat completions
- Document d'analyse exhaustif généré: `ANALYSE_EXHAUSTIVE_ECOSYSTEME_2026-03-21.md`
### 2026-03-21 (session 4)
- `mistral_dataset_pipeline.py` créé dans mascarade/finetune/ : pipeline merge→validate→upload→finetune
- 3 domaines configurés: kicad (1 source), spice-embedded (3 sources), full (10 sources)
- Déduplication MD5, injection system prompt automatique, split train/val 95/5
- CLI: validate, merge-kicad, merge-spice-embedded, upload, full, audit-all
- Datasets existants confirmés: 12 JSONL ~176 MB dans mascarade-datasets/ (virtiofs deadlock bloque lecture directe)
- Recherche web format Mistral fine-tune 2026: ChatML JSONL, min 200 exemples, loss sur assistant uniquement
- Mistral Forge (enterprise custom models) lancé mars 2026 — nouvelle option pour fine-tune avancé
- Pipeline prête pour exécution sur VM: `python3 mistral_dataset_pipeline.py full --datasets-dir ../mascarade-datasets/ --domain kicad`
### 2026-03-22 (session 5)
- `MISTRAL_DOCS_REFERENCE_2026-03-21.md` compilé : référence complète API (469 lignes)
- Fine-tune API toujours fonctionnelle malgré label "deprecated" → pipeline compatible
- Mistral Forge (enterprise custom models) à surveiller comme alternative
- Document Library (Beta Libraries) = RAG natif Mistral → complémentaire à Outline
- Modèles candidats: Mistral Small 4 (119B), Voxtral Mini Realtime (4B STT)
- Audit HuggingFace clemsail : 4 modèles + 8 datasets → cohérent avec pipeline locale
- `mistral_agents_beta_api.py` créé dans mascarade/agents/ avec MistralLibraryClient (T-MS-013 prep)
- Note: les 2 pipelines fine-tune (HF local TinyLlama/Qwen + Mistral API) sont complémentaires
- **Prochaines étapes VM** : merge datasets → upload → launch fine-tune jobs
### 2026-03-22 (session 6)
- Audit complet AI Studio via browser automation :
- Fichiers: 0 fichiers uploadés — prêt pour pipeline
- Fine-tune Modèles: 0 — Fine-tune Jobs: 0 — Batches: 0
- IA Documentaire: OCR playground opérationnel (10 docs, 50 Mo, PDF/images, API 1000 pages/doc)
- Audio STT: Beta offline+realtime (10 fichiers, 1024 Mo, MP3/WAV/MP4/MOV/WEBM)
- Vibe CLI: clé API active, quota indisponible pour l'organisation
- Codestral: clé API active, endpoints FIM (`codestral.mistral.ai/v1/fim/completions`) + Chat confirmés
- **Découverte limitation** : codestral-latest et devstral-latest ne supportent pas les builtin connectors AI Studio (Code, Image, Recherche) — erreur API 3004
- 4 agents passés en v2 avec températures cibles (voir TODO 23 session 6)
- **Prochaines étapes** : Upload datasets JSONL via API → Launch fine-tune jobs → Batch benchmark
### 2026-03-22 (session 7)
- **OpenAI Platform configuré** comme provider complémentaire dans l'écosystème multi-LLM :
- Billing: $50 credit, auto-recharge ON ($25 @ $15 threshold)
- Admin key "claude" créée pour administration globale
- Assistants API deprecated (suppression août 2026) → Responses API recommandée
- **3 projets OpenAI** pour isolation par écosystème :
- Default project: `proj_OwtOT7Ws1BtPVsKFkuI3VFpM`
- Mascarade: `proj_Z6TszEfikDtBSfn5rIeaJnQI`
- Kill_LIFE: `proj_CYBNMcd3L1ml9IZHC1tqdpQh`
- **Clés API par projet** :
- mascarade-router → Mascarade (All permissions)
- kill-life-governance → Kill_LIFE (All permissions)
- Architecture: Mistral (agents+fine-tune) + OpenAI (GPT-4o/o3, embeddings, Responses API) = providers complémentaires dans Mascarade router
- **Prochaines étapes** : Configurer OpenAI provider dans Mascarade router → Intégrer GPT-4o comme fallback → Upload datasets JSONL Mistral
### 2026-03-22 (session 8)
- **Lot 23 T-MA-037/038 complétés** : Migration Beta Conversations API terminée
- `mistral_agents_tui.sh` réécrit (abstraction layer, fallback, handoff)
- `mistral_agents.py` provider créé dans mascarade/router/providers/ (MistralAgentsProvider)
- T-MS-023 (Codestral FIM) peut maintenant s'appuyer sur le provider agents existant
- **Prochaines étapes** : Upload datasets JSONL via API (T-MS-002/003) → Launch fine-tune jobs (T-MS-010/011)
### 2026-03-22 (session 9)
- **T-MS-023 clôturé dans le repo actif** :
- implémentation dans `/Users/electron/Documents/Projets/mascarade`
- aucune création de provider `codestral_fim.py`
- route core `/v1/api/providers/codestral/fim` et façade API `/api/providers/codestral/fim`
- couverture de tests ajoutée côté core et API
- **Décision complémentaire** :
- cockpit `Kill_LIFE` reste direct-to-Mistral pour Studio
- le runtime Mascarade reste responsable du FIM via le provider `codestral` du routeur actif
## Gouvernance de dossier — source de verite unique
Decision verrouillee a partir du 2026-03-22.
Dossiers autorises:
- Kill_LIFE tracking / cockpit: `/Users/electron/Documents/Lelectron_rare/Kill_LIFE`
- Mascarade code actif: `/Users/electron/Documents/Projets/mascarade`
Dossier interdit pour ce lot:
- `/Users/electron/Documents/Lelectron_rare/Github_Repos/Perso/mascarade-main`
Regle operative:
- toute integration Studio qui touche Mascarade doit viser uniquement `/Users/electron/Documents/Projets/mascarade`
- tout suivi de lot `T-MS-*` reste uniquement dans `Kill_LIFE/docs/plans/24_todo_integration_mistral_studio.md`
- ne pas reutiliser de chemins historiques ou de copies paralleles dans les prochaines sessions
Garde-fou operateur disponible:
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/mistral_workspace_guard.sh`
- ce script doit etre utilise avant tout lot local Mistral si un doute existe sur la copie Mascarade active
## Session 2 — 2026-03-22 — Gate locale avant upload Studio
Travail local uniquement dans `Kill_LIFE`.
Fait:
- `/Users/electron/Documents/Lelectron_rare/Kill_LIFE/tools/cockpit/dataset_audit_tui.sh` sert maintenant de gate locale avant `T-MS-002` et `T-MS-003`
- le statut `preflight` doit etre consulte avant tout upload dataset vers Mistral Studio
Impact:
- si `preflight` n'est pas vert, ne pas lancer `T-MS-002/003`
- si `preflight` est vert, le blocage restant est explicitement cote VM / upload runtime
## Session 3 — 2026-03-22 — Racines Mascarade canoniques pour les lots Studio
Fait:
- les racines Mascarade utiles au mesh sont maintenant figees dans `tools/cockpit/mascarade_mesh_env_sync.sh`
- `cils` est confirme en layout macOS avec racine active `/Users/cils/mascarade-main`
Impact pour les lots `T-MS-*`:
- ne pas utiliser d'heuristique `/home/*` pour `cils`
- reutiliser la cartographie machine -> racine du script avant toute propagation d'env ou preparation runtime
## Session 4 — 2026-03-22 — Convention de cle Mistral pour Studio vs governance
Decision retenue:
- les lots Studio / Mascarade restent sur `MISTRAL_API_KEY`
- la cle `kill-life-governance` ne doit pas etre rebranchee dans Mascarade tant qu'aucun consumer canonique Studio n'existe
- la cle governance est reservee aux scripts `Kill_LIFE` via `MISTRAL_GOVERNANCE_API_KEY`
Impact pour `T-MS-*`:
- ne pas introduire de seconde variable Mistral cote Mascarade sans consumer explicite
- conserver `MISTRAL_API_KEY` comme seule interface Mistral canonique dans `/Users/electron/Documents/Projets/mascarade`
docs/plans/25_todo_hypnoled_pilote.md
+142
View File
@@ -0,0 +1,142 @@
# TODO 25 — Projet Hypnoled : Cas pilote Mascarade + Kill_LIFE
> **Owner**: PM-Mesh + Architect
> **Date création**: 2026-03-22
> **Statut global**: 🟢 Phase 1 — Reviews Forge complètes, rapport livré
> **Client**: M. Garnier (`Clients/Garnier/`)
> **Projet**: `Projets/Hypnoled/`
---
## Contexte
Hypnoled est le premier projet client réel utilisé comme **cas pilote end-to-end** pour valider l'infrastructure multi-LLM Mascarade + Kill_LIFE. Le projet combine hardware (PCB KiCad, DALI), simulation (LTspice), et firmware (ESP32).
## Inventaire assets
### Hardware (4 projets KiCad)
| Projet | Fichier | Sous-schémas | Statut |
|--------|---------|-------------|--------|
| DALI PCB (main) | `hardware/pcb/DALI_PCB_main/` | DALI, esp32, audio, audio2led, MCP_power, UI | **Actif** (rev 0.1, 2026-02-10) |
| DALI PCB (backup) | `hardware/pcb/DALI_PCB_backup/` | idem | Backup |
| Audio2LED | `hardware/pcb/Audio2LED_PCB/` | standalone | Audio-réactif |
| Legacy | `hardware/pcb/PCB_legacy/` | standalone | Prototype 2021 |
### Composants DALI identifiés
- 1SMA4746 (Zener protection)
- BSS123 (N-MOSFET bus DALI)
- EL357N optocoupler (isolation galvanique)
- MB10S (pont redresseur 16V DALI)
- STN1HNK60 (MOSFET HV 600V — driver DALI)
- STN93003 (PNP amplificateur)
- BC857 (PNP interface)
- ESP32 (MCU principal)
### Simulation
- `hardware/simulation/hypnoled.asc` — LTspice, circuit LED driver
- `hardware/simulation/hypnoled simple.asc` — version simplifiée
### BOMs
- `Audio2LED_PCB/BOM.csv`
- `PCB_legacy/BOM.csv`
- `PCB_2021-03-31/BOM_*.csv`
---
## Phase 0 — Structuration (DONE)
- [x] T-HP-001: Créer fiche client Garnier (`Clients/Garnier/fiche_client.md`)
- [x] T-HP-002: Structurer projet Hypnoled (hardware/pcb, mecanique, simulation, docs, photos)
- [x] T-HP-003: Migrer tous les fichiers depuis `Fauteuil_Hypnotherapie/` et `Pro_Garnier/`
- [x] T-HP-004: Indexer les fichiers KiCad (4 projets, 7 sous-schémas)
- [x] T-HP-005: Test connectivité Forge/Codestral sur schéma DALI réel ✅ (200 OK, 800 tokens)
## Phase 1 — Agents Kill_LIFE sur Hypnoled
- [x] T-HP-010: **Forge review PCB** — ✅ 6/6 sous-schémas reviewés par Codestral (22 mars 2026)
- DALI.kicad_sch → 660 in / 952 out — 1 critique (Zener 15V), 1 avert., 3 recos
- esp32.kicad_sch → 785 in / 1222 out — 2 critiques (double ESP32, USB-C CC), 2 avert., 3 recos
- audio.kicad_sch → 529 in / 771 out — 1 critique (PCM5122 alim), 1 avert., 3 recos
- audio2led.kicad_sch → 560 in / 712 out — 1 critique (IRF3415 surdim.), 1 avert., 3 recos
- MCP_power.kicad_sch → 624 in / 961 out — 2 critiques (chaîne alim incohérente), 1 avert., 3 recos
- UI.kicad_sch → 478 in / 813 out — 1 critique (MPR121 addr I2C), 1 avert., 3 recos
- **Total : 3 636 tokens in, 5 431 tokens out, 8 critiques, 7 avertissements, 18 recommandations**
- [x] T-HP-011: **Sentinelle monitoring** — ✅ Métriques collectées (22 mars 2026)
- 6 appels API, 9 067 tokens total, taux succès 100%, coût ~0.009€
- [x] T-HP-012: **Tower documentation** — ✅ Rapport généré (22 mars 2026)
- PDF : `Clients/Garnier/rapports/review_hardware_hypnoled_2026-03-22.pdf`
- Markdown : `Projets/Hypnoled/docs/reviews/forge_review_DALI_PCB_2026-03-22.md`
- [ ] T-HP-013: **BOM analysis** — Parser les BOMs CSV et proposer des alternatives composants (coût, disponibilité)
## Phase 2 — Simulation et Firmware
- [ ] T-HP-020: **Forge SPICE review** — Analyser `hypnoled.asc` avec Codestral, proposer optimisations
- [ ] T-HP-021: **Forge firmware** — Générer skeleton firmware ESP32 pour contrôle DALI (I2C + UART)
- [ ] T-HP-022: **Benchmark Hypnoled** — 10 prompts Hypnoled-spécifiques dans le benchmark T-MA-021
## Phase 3 — Fine-tune enrichissement
- [ ] T-HP-030: **Dataset KiCad** — Extraire les schémas Hypnoled en paires prompt/response pour enrichir le dataset fine-tune T-MA-016
- [ ] T-HP-031: **Dataset SPICE** — Extraire les simulations LTspice pour enrichir T-MA-017
- [ ] T-HP-032: **Évaluation post fine-tune** — Re-run les reviews Forge sur Hypnoled avec le modèle fine-tuné vs base → mesurer l'amélioration
---
## Test initial validé (22 mars 2026)
```
Provider: Mistral (Codestral-latest / Forge)
Clé: mascarade-router (708z...7kG)
Prompt: Review schéma DALI Hypnoled
Résultat: 200 OK — 315 tokens in, 800 tokens out
Qualité: Bonne — identifie protection Zener, isolation optocoupleur, dimensionnement MOSFET HV
```
---
## Review complète Forge (22 mars 2026)
```
Provider: Mistral (Codestral-latest / Forge)
Clé: mascarade-router (708z...7kG)
Schémas reviewés: 6/6 (DALI, esp32, audio, audio2led, MCP_power, UI)
Total composants analysés: 333
Total tokens: 9 067 (3 636 in / 5 431 out)
Résultats: 8 critiques, 7 avertissements, 18 recommandations
Top 3 critiques:
1. Architecture alimentation incohérente (MCP_power)
2. Double ESP32 non justifié (esp32)
3. Adresse I2C MPR121 non configurée (UI)
Rapport: Clients/Garnier/rapports/review_hardware_hypnoled_2026-03-22.pdf
```
---
## Gate d'execution 2026-03-22
Constat repo:
- les assets Hypnoled references dans ce TODO ne sont pas presents dans le checkout courant `Kill_LIFE`
- les prochains lots Hypnoled sont donc `blocked-by-missing-assets-in-current-checkout` tant que les schemas, boards, BOMs et rapports references ne sont pas materialises ici
Ordre d'execution retenu des que les assets sont presents:
1. `T-HP-013` — analyse BOM et alternatives composants
2. `T-RE-297` — contrat `fab package`
3. `T-HP-035` — parite `kicad-happy`
4. `T-HP-033` — canary `Quilter`
5. `T-HP-034` — evaluation `PCB Designer AI`
Sortie attendue pour `T-HP-013`:
- BOM normalisee
- alternatives composants
- mapping fournisseur `LCSC/JLCPCB` quand possible
- recommandations cout/disponibilite
- statut `assembly-ready` ou `blocked`
## Delta 2026-03-22 - PCB AI / BOM / fabrication
- [ ] T-HP-033: **Quilter canary route** — Executer un aller-retour `KiCad -> Quilter -> package fab` sur une carte Hypnoled et comparer le candidat au flux YiACAD local.
- [ ] T-HP-034: **PCB Designer AI fast-fab lane** — Evaluer une voie `schema -> layout -> export fabrication` sur un sous-ensemble Hypnoled, sans contourner le gate local `BOM/DRC/provenance`.
- [ ] T-HP-035: **kicad-happy playbook parity** — Rejouer un lot `review schema + BOM sourcing + JLCPCB prep` et comparer les sorties aux prompts `Forge` et a `review.bom`.
docs/plans/26_todo_integration_eda_ai_tools.md
+118
View File
@@ -0,0 +1,118 @@
# TODO 26 — Intégration outils EDA+IA dans Mascarade
> **Owner**: Architect + SM-Ops
> **Date création**: 2026-03-22
> **Statut global**: 🟡 Realignment — spec cadree, implementation absente dans le repo actif
> **Référence**: T-EDA-001 (PCB Designer AI), T-EDA-002 (Quilter), T-EDA-003 (kicad-happy)
---
## Contexte
Intégration de 3 outils EDA+IA dans l'architecture Mascarade pour couvrir le workflow complet :
schéma → placement → routage IA → export → fabrication JLCPCB.
Ces outils complètent le KiCadRouterProvider existant (routage interne) et le MistralProvider (review Forge).
## Outils intégrés
| Outil | Type | Chemin cible dans le repo actif | Rôle |
|-------|------|-------------------|------|
| PCB Designer AI | Provider | `core/mascarade/router/providers/pcbdesigner.py` *(planned, absent du repo actif)* | Upload schema -> IA place+route -> export Gerber -> commande JLCPCB one-click |
| Quilter | Provider | `core/mascarade/router/providers/quilter.py` *(planned, absent du repo actif)* | Routage physique+RL, candidats multiples, scores SI/thermal/DFM |
| kicad-happy | Agent | `core/mascarade/agents/kicad_happy_agent.py` *(planned, absent du repo actif)* | Analyse schema/PCB, BOM extract, sourcing LCSC, export JLCPCB, DFM check |
## Tâches
### Phase 1 — Realignment + spec-ready
- [ ] **T-EDA-001** : Créer `PCBDesignerProvider` — API REST, 5 actions (upload/status/export/order/rules), design rules JLCPCB/PCBWay
- [ ] **T-EDA-002** : Créer `QuilterProvider` — 6 actions (submit/status/candidates/download/constraints/stackup), presets impedance
- [ ] **T-EDA-003** : Créer `KiCadHappyAgent` — 7 skills, fallback S-expr parser, base LCSC 15+ composants, export BOM multi-format
- [ ] **T-EDA-004** : Enregistrer providers dans `providers/__init__.py` (try/except pattern)
- [ ] **T-EDA-005** : Enregistrer agent dans `agents/__init__.py`
### Reality check (2026-03-22)
- Repo Mascarade actif confirme: `/Users/electron/Documents/Projets/mascarade`
- Fichiers absents dans le repo actif:
- `core/mascarade/router/providers/pcbdesigner.py`
- `core/mascarade/router/providers/quilter.py`
- `core/mascarade/agents/kicad_happy_agent.py`
- Aucun statut `done` n'est autorise sur `T-EDA-001` a `T-EDA-005` tant que:
- le fichier n'existe pas dans le repo actif
- il est branche au routeur ou registre approprie
- la source de verite `Kill_LIFE` et le repo Mascarade actif sont alignes
### Phase 2 — Tests et validation
- [ ] **T-EDA-010** : Test unitaire `PCBDesignerProvider` — mock aiohttp, tester 5 handlers
- [ ] **T-EDA-011** : Test unitaire `QuilterProvider` — mock aiohttp, tester 6 handlers + presets
- [ ] **T-EDA-012** : Test unitaire `KiCadHappyAgent` — parser S-expr sur `DALI.kicad_sch`, BOM extract sur `bom.csv`
- [ ] **T-EDA-013** : Test intégration — workflow complet : parse schéma → BOM → sourcing LCSC → export JLCPCB
- [ ] **T-EDA-014** : Validation sur Hypnoled — soumettre `DALI_PCB_main` via PCBDesigner et Quilter
- blocages actuels:
- `API keys required`
- `Hypnoled assets missing in current checkout`
### Phase 3 — Router intelligence
- [ ] **T-EDA-020** : Ajouter routing rules dans `mascarade_config.yaml` — quand router vers pcbdesigner vs quilter vs kicad_router
- [ ] **T-EDA-021** : Scoring adaptatif — comparer résultats PCBDesigner vs Quilter sur même board, ajuster quality_rank
- [ ] **T-EDA-022** : Pipeline chaîné : kicad-happy (analyse+BOM) → quilter (routage) → pcbdesigner (commande JLCPCB)
### Phase 4 — Enrichissements
- [ ] **T-EDA-030** : Étendre base LCSC dans `KiCadHappyAgent` — parser catalogue JLCPCB Assembly Parts
- [ ] **T-EDA-031** : Intégrer prix temps-réel LCSC/DigiKey via API
- [ ] **T-EDA-032** : DFM check avancé — via API Quilter ou PCBDesigner, pas juste heuristiques locales
- [ ] **T-EDA-033** : Support Altium import/export dans les 2 providers
## Architecture
```
┌─────────────┐
│ Mascarade │
│ Router │
└──────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
┌──────▼──────┐ ┌─────▼──────┐ ┌──────▼──────┐
│ PCBDesigner │ │ Quilter │ │ KiCadRouter │
│ Provider │ │ Provider │ │ Provider │
│ (externe) │ │ (externe) │ │ (interne) │
└─────────────┘ └────────────┘ └─────────────┘
│ │
│ ┌───────────┘
│ │
┌──────▼────▼──────┐
│ KiCadHappy │
│ Agent │
│ (analyse+BOM) │
└──────────────────┘
│
┌──────▼──────┐
│ JLCPCB │
│ Fabrication │
└─────────────┘
```
## Métriques Phase 1
| Métrique | Valeur |
|----------|--------|
| Fichiers implémentés dans le repo actif | 0 |
| Fichiers spécifiés / prévus | 3 (2 providers + 1 agent) |
| Actions PCBDesigner prévues | 5 (upload, status, export, order, rules) |
| Actions Quilter prévues | 6 (submit, status, candidates, download, constraints, stackup) |
| Skills kicad-happy prévues | 7 (analyze_schematic, analyze_pcb, bom_extract, bom_export, component_source, dfm_check, review) |
| Composants LCSC ciblés | 15+ |
| Formats export BOM ciblés | 3 (JLCPCB, DigiKey, Mouser) |
| Presets contraintes ciblés | 3 (jlcpcb_2layer, jlcpcb_4layer, hypnoled_dali) |
## Prochaine action
1. Realigner ce lot et la cartographie ecosyteme sur l'etat reel du repo actif.
2. Fermer d'abord la chaine locale `fab package` (`BOM + DRC + Gerber/drill + provenance`) dans `Kill_LIFE`.
3. Implementer `T-EDA-001` a `T-EDA-005` seulement apres validation du contrat `fab package`.
docs/plans/README.md
+5
View File
@@ -26,6 +26,11 @@ Ces plans sont des **runbooks** : tu peux les suivre tels quels, ou les transfor
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)
---
docs/plans/REPO_DEEP_ANALYSIS_2026-03-11.md
+45 -37
View File
@@ -1,50 +1,58 @@
# Repo Deep Analysis Plan — Kill_LIFE — 2026-03-11
# Repo Deep Analysis Plan — Kill_LIFE — 2026-03-20
## Mission
Rendre `Kill_LIFE` plus lisible comme socle canonique runtime/spec-first:
Rendre le projet totalement pilotable via:
- spec-first,
- carte fonctionnelle explicitée (Mermaid),
- séquences opérationnelles complètes,
- gestion TUI des actions + logs,
- gouvernance agentique cohérente.
- diagrammes de sequence d'execution
- carte fonctionnelle des surfaces produit
- README et docs/plans relies au contrat multi-repo courant
## Agents actifs
## Agents actifs (actifs à date)
| Role | Mission |
| --- | --- |
| `embedded-systems-auditor` | cadrage global et priorisation |
| `workflow-map-curator` | carte fonctionnelle `specs/workflows/tools/hardware/firmware` |
| `mcp-runtime-analyst` | sequences `workflow -> local action/github dispatch -> evidence` |
| `firmware-doctor` | audit firmware/PlatformIO si blocages ou regressions runtime |
| `readme-curator` | alignement README/docs/plans |
| `PM` | arbitrage, priorisation, suivi des lots, clôture des jalons |
| `Architect` | cartes fonctionnelles + séquences d’exécution + ADR |
| `Firmware` | revue chaîne firmware/CI locale |
| `Hardware` | revue CAD/hardware + loops matériels |
| `QA` | sécurité, compliance, tests, preuves |
| `Doc` | alignement docs/README/runbooks |
## Deliverables
## Livrables de la refonte
- diagrammes de sequence `local` et `github`
- carte fonctionnelle canonique
- README enrichi de pointeurs vers le plan actif
- `docs/REFACTOR_MANIFEST_2026-03-20.md` (manifest opérationnel)
- `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md` (carte fonctionnelle)
- `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md` (sequence locale)
- `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md` (sequence GitHub)
- `docs/AGENTIC_LANDSCAPE.md` (topologie agentic)
- `docs/plans/12_plan_gestion_des_agents.md` (gestion agents)
- `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md` (lot-chain)
- `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md` (veille OSS intégrée)
## Status
## Analyse IA intégrée
- `K-DA-001` ferme par `docs/KILL_LIFE_FEATURE_MAP_2026-03-11.md`
- `K-DA-002` ferme par `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
- `K-DA-003` ferme par `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
- `K-DA-004` ferme par la synchronisation `docs/RUNBOOK.md`, `docs/index.md`, `docs/workflows/README.md`, `docs/AI_WORKFLOWS.md`, `docs/evidence/evidence_pack.md`
- `K-DA-006` ferme par `.github/workflows/evidence_pack.yml`, `docs/evidence/evidence_pack.md` et `docs/EVIDENCE_ALIGNMENT_2026-03-11.md`
- `K-DA-007` ferme par `tools/bootstrap_python_env.sh`, `tools/ci_runtime.py`, `tools/collect_evidence.py`, `.github/workflows/evidence_pack.yml` et `test/test_firmware_evidence.py`
- `K-DA-008` ferme par `.github/workflows/evidence_pack.yml`, `tools/compliance/requirements-platformio.txt` et la mise en cache `pip` / `PlatformIO`
- `K-DA-009` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et la doc evidence/GitHub workflow
- `K-DA-010` ferme par `tools/auto_check_ci_cd.py`, `docs/evidence/ci_cd_audit_summary.md` et la doc evidence/GitHub workflow
- `K-DA-011` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et le focus automatique sur les lanes en echec
- `K-DA-012` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et la compaction des chemins absolus dans le rendu Markdown evidence
- `K-DA-013` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et la reduction des signaux listeux en resumes courts
- `K-DA-014` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et l'extraction d'un bloc `Artifact summary` dedie dans le rendu Markdown evidence
- `K-DA-015` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et l'exposition `required_files` / `missing` dans `Artifact summary`
- `K-DA-016` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et la detection de drift `summary ok` dans `Artifact summary`
- `K-DA-017` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et le recalcul des artefacts encore presents en cas de drift `summary ok`
- `K-DA-018` ferme par `tools/auto_check_ci_cd.py`, `test/test_auto_check_ci_cd.py` et la separation explicite `Source artifacts` / `Evidence files`
- `K-DA-019` ferme par la relecture complete `KILL_LIFE_PIO_MODE=native ./.venv/bin/python tools/auto_check_ci_cd.py`, la regeneration du sidecar `docs/evidence/ci_cd_audit_summary.md` et la confirmation que la doc evidence restait correcte sans correction additionnelle
- Evaluer les overlays IA utilisés (`ZeroClaw`, `LangGraph`, `AutoGen`, MCP) en mode pilote,
- valider les points d’orchestration hors dépendance bloquante,
- encadrer les appels externes par label/scope/gates,
- documenter chaque expérimentation dans une note de lot avec seuil de rollback.
## Next tasks
## Plan d’exécution
- `K-DA-020` isoler le blocage restant de `bash tools/test_python.sh --suite stable` autour des deltas MCP runtime hors lot
- Prioriser P0 : cohérence docs/plans/README + cartes/séquences.
- P1 : durcir la gestion des logs (lecture, analyse, purge) et la preuve des actions.
- P2 : améliorer la matrice de sous-agents + rapports hebdo.
## Développements de plan suivants
- `K-DA-001` à `K-DA-004` clos via les artefacts de carte/séquence/couverture.
- `K-DA-020` à traiter via `tools/repo_state` simplifié puis re-vérification CI.
- Toutes les itérations doivent pointer vers un lot en cours dans `specs/04_tasks.md`.
## Etat courant (à réactualiser via lot-chain)
1. Alignement manifeste/specs/plans: `en cours`
2. Cartographie + séquences: `en cours`
3. Révisions repo-state et logs TUI: `en cours`
4. Matrices agents/sous-agents: `en cours`
docs/references/github_ecosystem_map.md
+226
View File
@@ -0,0 +1,226 @@
# Cartographie GitHub — Écosystème Multi-LLM Mascarade
> **Dernière MAJ**: 2026-03-22 (session 13 — +2 providers EDA, +1 agent kicad-happy)
> **Objectif**: Référencer les repos GitHub officiels des providers et outils pertinents pour l'infrastructure Mascarade + Kill_LIFE
---
## 🔷 Anthropic — github.com/anthropics (77 repos)
### SDKs (providers Mascarade)
| Repo | Stars | Langage | Usage Mascarade |
|------|-------|---------|-----------------|
| **anthropic-sdk-python** | 3.0k | Python | Provider `claude.py` — SDK principal |
| **anthropic-sdk-typescript** | 1.7k | TypeScript | Frontend/API gateway |
| **anthropic-sdk-go** | 918 | Go | — |
| **anthropic-sdk-java** | 260 | Kotlin | — |
| **anthropic-sdk-csharp** | 192 | C# | — |
| **anthropic-sdk-php** | 118 | PHP | — |
| **anthropic-sdk-ruby** | 309 | Ruby | — |
### Agents & Tools
| Repo | Stars | Description | Pertinence |
|------|-------|-------------|------------|
| **skills** | 99.3k | Public Agent Skills registry | Skills de référence pour Kill_LIFE agents |
| **claude-code** | 81k | CLI coding agent (Shell) | Outil de dev principal |
| **claude-agent-sdk-python** | 5.6k | SDK agents Python | Potentiel orchestrateur alternatif Mascarade |
| **claude-code-action** | 6.4k | GitHub Actions CI/CD | CI Kill_LIFE / Mascarade |
| **claude-plugins-official** | 13.9k | Plugin directory officiel | Référence plugins Kill_LIFE |
### Ressources & Learning
| Repo | Stars | Description |
|------|-------|-------------|
| **claude-cookbooks** | 35.6k | Notebooks/recettes Claude |
| **prompt-eng-interactive-tutorial** | 33.9k | Tutoriel prompt engineering |
| **courses** | 19.7k | Cours éducatifs Anthropic |
| **claude-quickstarts** | 15.5k | Quickstart apps déployables |
### Anthropic Platform configuré
| Élément | Valeur |
|---------|--------|
| Organisation | L'électron rare |
| Plan | Evaluation access (free tier) |
| Workspace | Default |
| Clé mascarade-router | `sk-ant-api03-bEo...hQAA` ✅ |
| Clé kill-life-governance | `sk-ant-api03-xKJ...zQAA` ✅ |
---
## 🟢 OpenAI — github.com/openai (234 repos)
### SDKs (providers Mascarade)
| Repo | Stars | Langage | Usage Mascarade |
|------|-------|---------|-----------------|
| **openai-python** | 30.3k | Python | Provider `openai.py` — SDK principal |
| **openai-node** | 10.8k | TypeScript | Frontend/API |
| **openai-go** | 3.1k | Go | — |
| **openai-java** | 1.4k | Kotlin | — |
### Agents
| Repo | Stars | Description | Pertinence |
|------|-------|-------------|------------|
| **codex** | 66.8k | CLI coding agent (Rust) | Concurrent Claude Code |
| **openai-agents-python** | 20.2k | Multi-agent framework Python | Référence pour architecture agents Mascarade |
| **openai-agents-js** | 2.5k | Multi-agent framework JS | — |
| **plugins** | 74 | OpenAI Plugins | Plugin architecture ref |
### Outils & ML
| Repo | Stars | Description | Pertinence |
|------|-------|-------------|------------|
| **whisper** | 96.4k | Speech Recognition | Potentiel module voix Mascarade |
| **tiktoken** | 17.6k | BPE tokenizer rapide | Token counting dans router |
| **evals** | 18k | Framework d'évaluation LLM | Benchmark T-MA-021 |
| **openai-cookbook** | 72.3k | Guides & exemples API | Recettes Responses API |
### Projets OpenAI Platform configurés
| Projet | ID | Clé |
|--------|----|-----|
| Default | `proj_OwtOT7Ws1BtPVsKFkuI3VFpM` | — |
| Mascarade | `proj_Z6TszEfikDtBSfn5rIeaJnQI` | mascarade-router |
| Kill_LIFE | `proj_CYBNMcd3L1ml9IZHC1tqdpQh` | kill-life-governance |
---
## 🟠 Mistral AI — github.com/mistralai (24 repos)
### SDKs (providers Mascarade)
| Repo | Stars | Langage | Usage Mascarade |
|------|-------|---------|-----------------|
| **client-python** | 716 | Python | Provider `mistral.py` + `mistral_agents.py` — SDK principal |
| **client-ts** | 131 | TypeScript | — |
### Inference & Fine-tune
| Repo | Stars | Description | Pertinence |
|------|-------|-------------|------------|
| **mistral-inference** | 10.7k | Lib inférence locale (Jupyter) | Référence formats modèles |
| **mistral-finetune** | 3.1k | Pipeline fine-tune officiel | **T-MA-016/017** — fine-tune KiCad/SPICE |
| **mistral-common** | 871 | Preprocessing/tokenization | Token counting Mistral |
### Agents & Tools
| Repo | Stars | Description | Pertinence |
|------|-------|-------------|------------|
| **mistral-vibe** | 3.6k | CLI coding agent Python | Concurrent Claude Code / Codex |
| **agent-client-protocol** | 4 | Fork ACP (éditeur↔agent) | Protocol standard agents |
| **cookbook** | 2.2k | Recettes Mistral | Exemples Beta API |
### Agents AI Studio configurés
| Agent | ID | Modèle | Temp |
|-------|----|--------|------|
| Sentinelle | `ag_019d124c...` | mistral-medium-latest | 0.1 |
| Tower | `ag_019d124e...` | magistral-medium-latest | 0.4 |
| Forge | `ag_019d1251...` | codestral-latest | 0.21 |
| Devstral | `ag_019d1253...` | devstral-latest | 0.17 |
### Divers
| Repo | Description |
|------|-------------|
| **platform-docs-public** (MDX) | Docs API publiques |
| **prom_client_python** (fork Prometheus) | Monitoring instrumenté |
| **zed-extensions** (fork Zed) | Extension éditeur Zed |
| **megablocks-public** (archive, fork Databricks) | MoE sparse training |
| **flyte** (fork Flyteorg) | Workflow orchestration |
---
## 📊 Comparatif CLI Agents (coding tools)
| Outil | Org | Stars | Langage | Licence |
|-------|-----|-------|---------|---------|
| **skills** | Anthropic | 99.3k | Python | — |
| **claude-code** | Anthropic | 81k | Shell | — |
| **codex** | OpenAI | 66.8k | Rust | Apache-2.0 |
| **mistral-vibe** | Mistral | 3.6k | Python | Apache-2.0 |
## 📊 Comparatif Agent Frameworks
| Framework | Org | Stars | Description |
|-----------|-----|-------|-------------|
| **claude-agent-sdk-python** | Anthropic | 5.6k | SDK agents Claude |
| **openai-agents-python** | OpenAI | 20.2k | Multi-agent workflows |
| **openai-agents-js** | OpenAI | 2.5k | Multi-agent JS |
| *(Conversations Beta API)* | Mistral | — | Agents via API Studio |
---
## 🔗 Mapping providers Mascarade → GitHub repos
```
mascarade/router/providers/
├── claude.py → anthropics/anthropic-sdk-python
├── openai.py → openai/openai-python
├── mistral.py → mistralai/client-python
├── mistral_agents.py → mistralai/client-python + Beta Conversations API
├── google.py → google (Gemini SDK)
├── bedrock.py → AWS SDK (boto3)
├── huggingface.py → huggingface_hub
├── ollama.py → ollama/ollama-python
├── llama_cpp.py → local inference
├── apple_coreml.py → coremltools
├── kicad_router.py → custom KiCad routing
├── pcbdesigner.py → planned provider path in active repo (T-EDA-001, Plan 26)
└── quilter.py → planned provider path in active repo (T-EDA-002, Plan 26)
mascarade/agents/
├── kicad_agent.py → KiCad schematic/PCB agent
├── kicad_happy_agent.py → planned agent path in active repo for BOM/LCSC/DFM (T-EDA-003, Plan 26)
├── spice_agent.py → LTspice simulation agent
├── components_agent.py → Component sourcing agent
└── freecad_agent.py → FreeCAD 3D/mechanical agent
```
---
## 💰 Synthèse Billing — Infrastructure Multi-LLM (22 mars 2026)
| Provider | Plan | Crédits | Billing | Limites clés |
|----------|------|---------|---------|--------------|
| **Mistral** | Le Chat Team (59,98 €/mois) + AI Studio Scale | 0,00 € (pay-as-you-go) | Visa ****-2046 | 6 RPS, 2M TPM, 10B tokens/mois, fine-tune ✅ |
| **OpenAI** | Pay as you go | **$50.00** | Auto-recharge ON ($25@$15) | Standard tier |
| **Anthropic** | Evaluation access (free) | **0** (nécessite achat) | — | 5 RPM, 10K input TPM, 4K output TPM |
### Providers Mascarade — Statut opérationnel
| Provider | Fichier | SDK | Clé API | Statut |
|----------|---------|-----|---------|--------|
| `claude.py` | ClaudeProvider | anthropic SDK | mascarade-router (sk-ant-...hQAA) | ✅ Validé (crédits requis) |
| `openai.py` | OpenAIProvider | openai SDK | mascarade-router (sk-proj-...) | ✅ Opérationnel ($50) |
| `mistral.py` | MistralProvider | mistralai SDK | mascarade-router (708z...7kG) | ✅ Connectivité validée |
| `mistral_agents.py` | MistralAgentsProvider | httpx (Beta API) | mascarade-router (708z...7kG) | ✅ 4 agents v2 — validé |
| `pcbdesigner.py` | PCBDesignerProvider | aiohttp (REST) | `PCBDESIGNER_API_KEY` (a configurer) | 🟡 Planned, not implemented in active Mascarade repo |
| `quilter.py` | QuilterProvider | aiohttp (REST) | `QUILTER_API_KEY` (a configurer) | 🟡 Planned, not implemented in active Mascarade repo |
---
## Actions suivantes
1. **mistral-finetune** → Cloner et tester pour T-MA-016/017 (fine-tune KiCad/SPICE datasets)
2. **openai evals** → Adapter framework pour benchmark T-MA-021
3. **claude-agent-sdk-python** → Évaluer comme orchestrateur alternatif au router Mascarade
4. **tiktoken** → Intégrer token counting OpenAI dans le router (estimation coûts)
5. **openai-agents-python** → Étudier patterns multi-agent pour A2A protocol (T-MA-030)
6. **Acheter crédits Anthropic** → Nécessaire pour activer le provider Claude en production
---
## 🟣 Outils EDA+IA — Providers spécialisés PCB (Plan 26)
| Outil | Type Mascarade | API / Source | Approche | Temps typique |
|-------|---------------|-------------|----------|---------------|
| **PCB Designer AI** | Provider | REST `api.pcbdesigner.ai/v1` | IA placement+routing → Gerber → JLCPCB one-click | 30min–2h |
| **Quilter** | Provider | REST `api.quilter.ai/v1` | Physique+RL, multi-candidat, scores SI/thermal/DFM | 2–6h |
| **kicad-happy** | Agent | GitHub (Claude Code skills) | Analyse schéma/PCB, BOM extract, sourcing LCSC, DFM | Secondes |
| **KiCad Router** | Provider (existant) | Autorouter KiCad interne | Routage offline local | Minutes |
### Pipeline chaine cible (T-EDA-022)
```
kicad-happy (analyse+BOM) → quilter (routage physique) → pcbdesigner (commande JLCPCB)
```
Note de realite:
- cette chaine est une cible d'architecture
- elle n'est pas implementee dans le repo Mascarade actif au 2026-03-22
- aucun provider/agent EDA n'est considere `done` tant que le fichier n'existe pas dans `/Users/electron/Documents/Projets/mascarade`
Canonical mapping and adoption notes:
- `docs/PCB_AI_FAB_INTEGRATION_MAP_2026-03-22.md`
- `specs/contracts/pcb_ai_fab_registry.json`
- `tools/cockpit/pcb_ai_fab_tui.sh`
docs/templates/DesignReview.md
Vendored
+8
View File
@@ -8,6 +8,8 @@
### Architecture
- [ ] Interfaces listées
- [ ] Sidebar / canvas / inspector explicités
- [ ] Command palette / search définies si applicables
- [ ] Modes de panne identifiés
- [ ] ADR écrits pour décisions clés
@@ -20,14 +22,20 @@
- [ ] Plan de validation
- [ ] Test matrix
- [ ] Evidence pack défini
- [ ] Playtest ou walkthrough opérateur prévu
### Sécurité / conformité
- [ ] Profil conformité choisi
- [ ] Politique anti-injection respectée
- [ ] Scope guard applicable
- [ ] Sorties IA explicitement signalées et réversibles
## Décisions
## Références Apple / UX
- [ ] HIG / IA générative reliées
- [ ] points d’insertion natifs documentés
## Actions
- [ ] Action 1
- [ ] Action 2
docs/templates/PlaytestReport.md
Vendored
+9
View File
@@ -5,11 +5,20 @@
- **Participants**:
## Hypothèses testées
- hiérarchie visuelle
- compréhension du statut
- trouvabilité des actions `review / sync / artifacts`
- compréhension de la provenance IA
## Observations
## Problèmes rencontrés
## Commandes / surfaces testées
- TUI:
- KiCad:
- FreeCAD:
## Améliorations
## Décision