MIRA_procedure_suite_top.txt — procédure de suite, séquence complète (17/10/2026)

========================================================
MIRA — PROCÉDURE DE SUITE — SÉQUENCE COMPLÈTE
Rédigé le : 17/10/2026
État au moment de la rédaction : VM fonctionnelle,
circuit de validation testé, interface maintenance OK.
========================================================

OBJECTIF DE CETTE PROCÉDURE
----------------------------
Passer de la VM actuelle (VirtualBox) à une clé USB
autonome, puis démarrer la construction de la base
neuronale de MIRA (Phase 0 et suite).

Ne pas brûler les étapes. Chaque étape doit être
validée avant de passer à la suivante.

========================================================
ÉTAPE 0 — CONTRÔLE GÉNÉRAL DE LA VM
========================================================

But : s'assurer que tout fonctionne correctement sur la
VM avant de toucher au disque. Ne rien modifier ici,
juste vérifier.

Contrôles à effectuer :
  [ ] Démarrage de la VM sans erreur
  [ ] Interface graphique (Xfbdev + flwm) opérationnelle
  [ ] Bouton "Lancer MIRA" → chat_ia.py s'ouvre
  [ ] MIRA répond correctement à :
        - "quel jour sommes-nous ?"  (réponse directe)
        - "qui t'a créé ?"           (Da Conceição Mario)
        - "quelle est ta première question ?" (mémoire)
  [ ] Bouton "Maintenance" → mode maintenance s'ouvre
  [ ] Bouton "Analyser" → auto_analyse.py se lance,
        rapport généré, fenêtre reste ouverte
  [ ] filetool.sh -b effectué (sauvegardes persistantes)
  [ ] Aucune erreur dans les logs

Si un contrôle échoue → corriger avant de continuer.
Si tout est vert → passer à l'Étape 1.

========================================================
ÉTAPE 1 — COPIE DU DISQUE VIRTUEL (.vdi)
========================================================

But : faire une copie de sécurité complète de la VM
avant tout clonage. Si quelque chose tourne mal sur
la clé, on peut toujours revenir ici.

Procédure :
  [ ] Éteindre la VM proprement (pas forcer)
  [ ] Depuis VirtualBox (hôte) : copier le fichier .vdi
        → lui donner un nom daté
        (ex. MIRA_VM_sauvegarde_AAAMMJJ.vdi)
  [ ] Vérifier que la copie est lisible
        (taille cohérente, pas 0 octet)
  [ ] Ne pas rallumer la VM originale avant la fin
        de l'Étape 2

========================================================
ÉTAPE 2 — CLONAGE SUR CLÉ USB
========================================================

But : transférer le contenu de la VM sur la vraie clé
USB finale (boot natif, hors VirtualBox).

Points d'attention :
  - Tiny Core 64 bits, BIOS classique (jamais EFI/UEFI)
  - Même procédure que l'installation VM :
      extlinux / SYSLINUX, pas GRUB
  - Vérifier la taille de la clé avant de commencer
  - Chown tc:staff après toute copie faite avec sudo
  - Piège ISO9660 rappel : noms tronqués à 8+3 chars
      → toujours renommer après copie

  [ ] Clé USB branchée et détectée
  [ ] Partitionnement et formatage ext4
  [ ] Copie du système Tiny Core 64 bits
  [ ] Installation du bootloader (extlinux)
  [ ] Transfert des fichiers MIRA_Project
  [ ] Transfert du modèle Phi-4 Mini (2,49 Go)
  [ ] Réglages permanents copiés
        (/opt/bootlocal.sh, kmaps, gpm)
  [ ] filetool.sh -b sur la clé

========================================================
ÉTAPE 3 — TEST DE RESTAURATION
========================================================

But : vérifier que la clé USB démarre et que MIRA
fonctionne correctement en dehors de VirtualBox.

  [ ] Démarrer le PC sur la clé USB (BIOS, pas VirtualBox)
  [ ] Interface graphique démarre correctement
  [ ] Répéter les mêmes contrôles qu'à l'Étape 0
  [ ] GPU visible ? (RTX 3060 — probablement non en v1,
        noté pour plus tard)
  [ ] Si tout OK → la clé est validée

En cas d'échec : revenir à la copie .vdi de l'Étape 1
et reprendre depuis l'Étape 2.

========================================================
ÉTAPE 4 — DIAGNOSTICS
========================================================

But : faire un état des lieux propre sur la clé USB
avant de commencer le développement du noyau.

  [ ] Lancer auto_analyse.py → lire le rapport complet
  [ ] Vérifier les logs de chat_ia.py
  [ ] Vérifier que maintenance/a_valider/ est vide
        (pas de propositions en attente oubliées)
  [ ] Confirmer que gestionnaire_specialites.py est
        au bon endroit (mira_ai/ia_neuronale/)
        avec la bonne classe GestionnaireSpecialites
  [ ] Noter tout ce qui semble anormal

========================================================
ÉTAPE 5 — PHASE 0 : SOCLE DU NOYAU
========================================================

But : poser les bases du nouveau noyau neuronal de MIRA
selon le Tome 3.0 / CONCEPTION v1.0.

Séquence Phase 0 (option a — Q3) :
  a. Contrat de contexte
       → créer le dictionnaire de contexte selon le
         schéma v1.0 figé (voir fichier
         MIRA_contexte_schema_v1_0_fige.txt)
       → clés N1 à N6, règles de priorité, erreurs[]

  b. Modèle factice
       → créer un module noyau_minimal.py qui accepte
         executer(contexte) -> contexte
       → sans Phi-4 Mini pour l'instant — juste la
         structure, les clés, le routage de base

  c. Benchmark
       → tester le modèle factice avec des cas simples
       → vérifier que le contexte circule correctement
         d'un module à l'autre
       → vérifier N6.meta.erreurs[] initialisé vide
         à chaque tour

  [ ] Tout le code passe par le circuit de validation
        (jamais appliqué sans validation humaine)
  [ ] py_compile après chaque fichier
  [ ] filetool.sh -b après chaque session

========================================================
SUITE (après Phase 0)
========================================================

Ordre prévu des phases :
  Phase 1 : persistance (mémoire entre sessions)
  Phase 2 : noyau minimal complet
  Phase 2b : intégration de chat_ia.py existant
  Phase 3 : outils déterministes
  Phase 4 : connexion Phi-4 Mini
  Phase 5 : mémoire structurée
  Phase 6 : bac à sable et validation renforcée
  Phase 7 : spécialités
  Phase 8 : auto-amélioration supervisée

Règles qui restent valables dans toutes les phases :
  - Le réseau est refusé à tous les modules en version 1
  - Tout code passe par le circuit de validation (10 étapes)
  - Validation humaine obligatoire avant toute application
  - Copie de sécurité avant toute modification importante
  - En BusyBox : répondre "y" (pas "o") aux confirmations

========================================================
FIN DU DOCUMENT
========================================================

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Défiler vers le haut