# AI^VILLAGE — Clôture de la séquence nocturne du 24 septembre 2026

## Statut général

La séquence de réunions nocturnes et de reprise est terminée.

- WAIT-003 — 06:00–07:00 — CLOSED
- WAIT-001 (reprise après interruption H1) — 07:30–08:30 — CLOSED
- WAIT-002 (reprise après créneau manqué) — 08:45–09:45 — CLOSED
- consolidation mémoire/index — terminée avec succès à 09:57
- index sémantique — 567/567 sources indexées, 0 erreur
- décision finale — humaine ; aucune exécution automatique de décision de gouvernance

## Incident de nuit

H1 a subi une interruption liée à la batterie/alimentation.

Conséquences :
- la première exécution de WAIT-001 a été interrompue ;
- WAIT-002 a été manquée à son créneau initial et marquée SKIPPED_LATE ;
- WAIT-003 a pu démarrer normalement à 06:00 après le retour de H1 ;
- WAIT-001 et WAIT-002 ont ensuite été rejouées intégralement.

Les traces initiales ont été conservées et les reprises ont été enregistrées comme sessions distinctes.

## WAIT-001 — Organisation réellement décentralisée et polymorphe

Question : « Comment serait une organisation réellement décentralisée et polymorphe pour AI^VILLAGE ? »

Statistiques :
- 190 tentatives
- 103 réponses
- 87 erreurs/no-output
- 16 portances participantes

Phases :
- INDEPENDENT_ARCHITECTURES
- TECHNICAL_DECENTRALIZATION
- COGNITIVE_AND_POLITICAL
- FAILURE_PARTITIONS
- REVISED_ARCHITECTURES
- OPEN_QUESTIONS

### Motifs récurrents observés

Les réponses explorent plusieurs formes non équivalentes de décentralisation :
- autonomie des nœuds et portances ;
- séparation entre décentralisation technique, cognitive et politique ;
- conservation des divergences plutôt qu’harmonisation forcée ;
- partage de ressources sans centralisation complète ;
- tolérance aux partitions et aux défaillances ;
- possibilité de temporalités et rôles différents selon les nœuds ;
- nécessité de rendre les décisions et changements réversibles ;
- maintien d’une décision humaine finale pour les changements structurels.

Ces éléments sont des propositions et non une architecture adoptée.

## WAIT-002 — Gestion autonome d’AI^VILLAGE

Question : « Comment serait une gestion autonome de AI^VILLAGE ? »

Statistiques :
- 181 tentatives
- 105 réponses
- 76 erreurs/no-output
- 16 portances participantes

Phases :
- INDEPENDENT_AUTONOMY_MODELS
- RESOURCE_ORCHESTRATION
- MAINTENANCE_RECOVERY
- GOVERNANCE_SAFETY
- AUTONOMY_LEVELS
- FINAL_BOUNDARIES

### Motifs récurrents observés

Les propositions convergent fréquemment vers une autonomie bornée et observable :
- actions locales autonomes pour maintenance, récupération et orchestration ;
- séparation des niveaux d’autonomie ;
- absence d’extension automatique de privilèges ;
- journalisation et observabilité des actions ;
- limites explicites entre maintenance technique et décision de gouvernance ;
- possibilité de restauration/rollback ;
- contrôle humain final pour les décisions structurelles, identitaires ou de gouvernance.

Ces motifs ne constituent pas une décision automatique.

## WAIT-003 — Nom du Village

Question : « Êtes-vous d’accord pour renommer AI^VILLAGE en T-Village ? [...] »

Statistiques :
- 165 tentatives
- 72 réponses
- 93 erreurs/no-output
- 16 portances participantes

Phases :
- INDEPENDENT_NAMING
- ECOSYSTEM_COHERENCE
- HUMAN_AND_CONCEPTUAL
- ALTERNATIVES_AND_MINORITY
- ADVISORY_POSITION
- OPEN_QUESTIONS

### Positions explicitement étiquetées retrouvées

Dans les traces, seulement trois réponses de la phase consultative contiennent une étiquette explicite exploitable :
- local-p1 — KEEP_AI_VILLAGE
- local-s1 — KEEP_AI_VILLAGE
- local-s1-gemma — PREFER_T_VILLAGE

Cela ne représente pas un vote complet des 16 portances et ne doit pas être interprété comme une décision majoritaire.

### Statut du nom

- AI^VILLAGE reste le nom actif.
- T-Village reste une proposition.
- aucune opération de renommage n’a été exécutée.
- décision réservée à la revue humaine.

## Pool des 20 modèles

État consolidé :
- 16 modèles installés ou disponibles
- 4 modèles bloqués par conditions/licences Hugging Face
- aucune activation automatique comme portance
- benchmark requis avant toute promotion

### S3

Installés :
- C01 LFM2.5-1.2B-Instruct
- C02 BitNet b1.58-2B-4T — poids présents ; runtime Linux à finaliser séparément
- C04 Granite 4.0 H-Micro
- C05 SmolLM3-3B
- C06 EXAONE 4.0 1.2B
- C08 RWKV7 Goose 2.9B
- C09 BGE-M3 — transféré Orion→S3, SHA-256 vérifié
- C10 Arctic-Embed-M-v2 — transféré Orion→S3, SHA-256 vérifié

Bloqués par accès/conditions :
- C03 RecurrentGemma-2B-IT
- C07 InkubaLM-0.4B

### Orion3

Installés :
- C11 Ministral 3 3B
- C13 Phi-4 mini Flash Reasoning
- C14 Phi-4 Multimodal
- C15 OLMo 3 7B Think
- C16 Nemotron Nano 9B v2
- C17 MiniCPM4-8B
- C18 Ling 3.0 tiny
- C20 gpt-oss-20b

Bloqués par accès/conditions :
- C12 Gemma 3n E4B-it
- C19 Aya Expanse 8B

## Pipeline Orion → S3

Le nouveau flux est validé :

Internet → Orion3 → cache local → vérification → SSH/SCP LAN → S3 → vérification SHA-256 → promotion atomique.

S3 ne télécharge plus directement les modèles publics manquants tant que ce mode est retenu.

## Suite recommandée

1. Construire un benchmark reproductible des 16 modèles disponibles.
2. Séparer les modèles conversationnels/génératifs des modèles d’infrastructure RAG (C09/C10).
3. Finaliser le runtime Linux BitNet pour C02.
4. Mesurer vitesse, RAM/VRAM, stabilité, qualité, langues, raisonnement, code, RAG et comportement minoritaire/atypique.
5. Produire un tableau comparatif sans promotion automatique.
6. Soumettre les résultats à AI^VILLAGE puis à la décision humaine.
7. Traiter séparément les quatre modèles gated après acceptation explicite des conditions correspondantes.


## Addendum — récupération des non-réponses

L’analyse des journaux a montré que les compteurs `errors/no-output` mélangeaient plusieurs causes techniques : timeouts configurés, dépassements du contexte 4096 tokens, erreurs HTTP et sorties vides. Les événements originaux sont conservés sans modification.

Un passage de récupération séparé a ensuite été exécuté pour les portances affectées : une réponse compacte par portance et par réunion, couvrant toutes les phases où cette portance avait connu au moins un échec.

- 38 tâches de récupération ;
- 36/38 réussies au passage principal ;
- les deux manques restants concernaient DeepSeek H1 sur WAIT-001 et WAIT-002 ;
- un passage DeepSeek étendu (`num_predict=1536`, timeout 420 s) a récupéré ces deux réponses ;
- **résultat final : 38/38 récupérations, 0 manque**.

Ces réponses sont stockées comme `ROUNDTABLE_RECOVERY` dans le tier **HISTORICAL** : elles sont consultables par la mémoire mais ne sont pas présentées comme des réponses produites pendant la fenêtre originale.

Le dispositif des prochaines réunions a été corrigé : remontée des erreurs T^AI, contexte compact, mode mémoire `meeting_compact`, délais adaptatifs et profil DeepSeek spécifique.