Architecture et design patterns

Dans Igris 3.6.1, core/ exécute et gouverne ; workspace/ conserve une mémoire lisible, versionnable et reprenable.

Architecture du Runtime

Le Runtime Igris articule le Mission Interpreter (intake canonique + MissionContract), le THINK Engine (boucle de raisonnement), le DAG/Scheduler (ordonnancement), le Context Manager (contexte projet, RAG, RTK) et le Capability Registry (Tools/Skills/Agents). Le Task Executor exécute les actions validées et produit des événements dans l'Event Runtime.

Schéma THINK Engine Igris 3.6.1 : boucle OBSERVE → APPRAISE → PLAN → ACT → VERIFY → LEARN
Figure — THINK Engine Igris 3.6.1. La lecture suit les étapes numérotées : compréhension de l’objectif et planification, cognition pré-exécution et Risk Gate, matérialisation des missions, exécution Think surveillée par le Runtime Guard, puis cognition post-exécution et clôture avec preuves. Le LLM propose des plans et des actions ; le système conserve la décision finale sur les chemins, les outils, les périmètres et la validation. Ouvrir la figure en taille réelle.

Continuité et récupération en 3.6.1

La continuité ne consiste plus à relancer un plan générique. Igris identifie le run visé, conserve son objectif et réutilise uniquement les résultats dont la preuve est encore valable.

Reprise du bon run

Une référence explicite ou une demande « continue le projet » reprend le plan courant sans créer une nouvelle série de tâches.

Réutilisation conditionnelle

Une tâche terminée est reprise seulement si sa signature correspond et si ses sorties attendues existent toujours.

Plan ciblé

Les corrections et mises à jour génèrent un petit DAG aligné sur la demande au lieu de rejouer toute la construction.

Une séparation structurelle

igris/
├── core/                  # moteur exécutable
│   ├── control_plane*.py  # API et contrôle
│   ├── sprint/            # Product Owner, DAG et Sprints
│   ├── context/           # assemblage du contexte
│   ├── tools/             # registre et effets bornés
│   ├── cognition.py       # 96 dimensions et mémoire
│   └── sdk/               # façade publique
└── workspace/             # mémoire opérationnelle IPRCA
    ├── inbox/             ├── projects/
    ├── ressources/        ├── casquettes/
    └── archives/

Vue d'ensemble de l'architecture

Le schéma ci-dessous donne une vue globale de l'architecture d'Igris 3.6.1 : SDK public (core.sdk.Igris), Context Manager, THINK Engine, DAG/Scheduler, Capability Registry, Execution Runtime (sandbox Docker, workers), Event Runtime (PostgreSQL + pgvector) et workspace IPRCA.

Vue d’ensemble de l’architecture Igris Engine 3.6.1 : Context Manager, sandbox, providers, contrôle et mémoire IPRCA
Figure — Vue d'ensemble de l'architecture Igris 3.6.1. Le schéma illustre les relations entre le SDK public, le Context Manager, le THINK Engine, le DAG/Scheduler, le Capability Registry, l'Execution Runtime (sandbox Docker, workers), l'Event Runtime (PostgreSQL + pgvector) et la mémoire file-based IPRCA. Ouvrir la figure en taille réelle.

Patterns et garde-fous

Patterns stables

  • Contexte stable avant le dynamique
  • Missions décrites comme un DAG
  • Résultat de tool avant validation
  • Mémoire IPRCA file-based

Interdits structurants

  • Pas d’état critique caché dans une conversation
  • Pas de succès affirmé sans preuve
  • Pas de secrets réels dans les prompts
  • Pas de dossier métier parasite à la racine