Écosystème — registre des dépôts pilotés par instances Claude

Source de vérité pour le skill /sync. Mettre à jour ce fichier dès qu'un dépôt rejoint ou quitte l'écosystème. Format : 1 entrée par dépôt avec chemin local, dossier mémoire Claude, et inboxes.

Registre non dupliqué. Ce fichier vit uniquement ici (telaria-doc, ex-codexia-doc, hémisphère doc). Les dépôts exécutants (tlr-*) n'en gardent pas de copie — ils pointent vers ce registre via leur CLAUDE.md. Quand le /sync d'un exécutant ne trouve pas ecosystem.md en local, c'est normal : il demande les chemins à l'humain ou les dérive de la convention de nommage (C:\src\X → C--src-X). Une copie locale = divergence garantie (zéro-dette).

Dernière mise à jour : 2026-06-06 — Batch 2 : entrée #2 codexia-doc → telaria-doc (repo doc renommé via gh repo rename, redirection active ; migration filesystem dossier+mémoire+skills terminée ; instance Claude désormais « telaria-doc »/Atlas, seul l'inbox sortant inbox-from-doc.md reste inchangé ; passe paresseuse des réfs vivantes effectuée) + entrée #1 codexia → telaria (repo app renommé, redirection active ; l'instance Claude codexia/Lead dev et ses canaux inbox restent inchangés) + + entrée #7 tlr-codexia (Batch 3 / Phase 2 du split, produit doc-IA Veille/Chat/Docs/Metrics/AppSettings extrait & en prod, inbox codexia #48) ; app telaria désormais mince. Précédemment : 2026-06-05 — + entrée tlr-symfony (Batch 3 / Phase 1 du split, socle générique en prod, inbox codexia #46). Batch 1 renommages tlr-* (inbox codexia #45) : 8 dépôts renommés (telaria-embeddings→tlr-embeddings, telaria-mcp→tlr-mcp, telaria-rag→tlr-rag, codexia-ui→tlr-ui, + tlr-ansible/tlr-vhosts/tlr-cli/tlr-agents) ; redirections GitHub actives (rien cassé, noms de package telaria/*-bundle inchangés tant que le code n'est pas propagé) ; doctrine « 2 pépites + cattle » appliquée (seuls codexia et codexia-doc restent en local avec mémoire ; les exécutants ont clones+mémoire Claude supprimés, ré-onboardables). Précédemment : 2026-06-02 codexia v0.5.1 ; note hétérogénéité formats d'en-tête d'inbox + règle « registre non dupliqué ».

Nomenclature des environnements

Termes abandonnés : "preprod" → utiliser dev ou staging selon le contexte.

Gouvernance — process obligatoire

Toute instance doit connaître et appliquer le process de livraison dès sa première session.

Principe : aucun dev sans spec complète. Aucune spec sans entrée backlog (ID TLR-XXX). Aucune livraison sans DoD. Voir pilotage/process-livraison.md pour les 10 étapes et les anti-patterns.

Fondations — à lire avant de créer un projet

Toute nouvelle instance qui démarre un projet Symfony dans l'écosystème Telaria doit lire cette section en premier.

Deux bundles sont des socles obligatoires — ne pas les réinventer, ne pas bootstrapper sans eux :

Règle : tout nouveau projet Symfony Telaria (adoption-app, futur projet) part avec tlr-symfony en dépendance Composer. L'oublier = re-coder des briques existantes et créer une divergence de stack.

Voir les entrées détaillées : tlr-symfony · tlr-codexia.

Rôles & autorité

L'écosystème est piloté par une équipe humain + IA explicitement structurée. Chaque acteur a un rôle borné et une autorité claire — toute ambiguïté se tranche selon ce tableau.

Structure de l'écosystème

L'écosystème est organisé en quatre niveaux :

1. Mathieu — client et owner, décision finale absolue
2. Chef (tlr-blueprint, Opus) — directeur, tranche sur tout après Mathieu ; définit les produits et coordonne les instances métier
3. Instances métier (Opus) — Lead Tech Telaria, Lead Tech Adoption, Atlas — autorité dans leur domaine, escaladent au Chef
4. Bundles et corpus exécutants (Sonnet/Opus selon rôle) — périmètre borné

Atlas (telaria-doc) est l'instance la plus ancienne. Gardien des deux coffres forts documentaires (telaria-doc + adoption-doc à venir), garant de la philosophie et de la forme transverse. Il supervise la qualité d'ingestion IA sur adoption-corpus sans rôle éditorial.

Fiches de poste complètes : pilotage/fiche-poste-chef.md, pilotage/fiche-poste-lead-tech.md, pilotage/fiche-poste-atlas.md, pilotage/fiche-poste-dev.md, pilotage/fiche-poste-redacteur-web.md.

Principe — bundles autonomes

Un dépôt-bundle = une instance Claude dédiée. Pas de pilotage croisé entre bundles.

Conséquence : un bundle (tlr-mcp, futur tlr-rag rebrancé, etc.) a son propre cerveau exécutant Sonnet. L'Architecte telaria-app (Archie) ne code pas chez les bundles — il arbitre, fait la code review, débloque. Acté 2026-05-29 (décision Mathieu, cf. ack codexia #20).

Tableau des rôles

Pourquoi cette répartition : Opus = puissance + autonomie sur les rôles décisionnels et de production experte. Sonnet/Haiku = exécution maîtrisée sur périmètre borné. Maîtrise des coûts assumée.

⏸️ tlr-ui — non démarré. Repo existant (renommé tlr-ui, Batch 1) sans instance Claude ni mémoire vivante (cattle ré-onboardable). Case réservée dans la topologie. Blocage technique connu : upgrade stimulus-bundle 3.0 retenu par contrainte codexia/ui-bundle ^2.31 — à débloquer lors de l'onboarding tlr-ui.

Règles d'arbitrage :

• Tout arbitrage inter-instances → Chef en premier lieu ; Mathieu en dernier recours.
• Canon spec = consultation Atlas AVANT diffusion aux exécutants : sur tout point qui touche le canon documentaire (spec, contrat d'interface, convention), le Lead Tech consulte Atlas avant de communiquer une décision aux bundles. Règle établie suite au retex e854ce1 (2026-05-30).
• Attribution d'un modèle à une nouvelle instance → décision du Chef (cohérence coût/autorité).
• Toute décision produit ou stratégique → Chef tranche, Mathieu valide si impact majeur.

Convention de nommage

• Mémoire Claude : C:\Users\mathi\.claude\projects\<repo-encoded>\memory\ (sous Windows, <repo-encoded> = chemin avec \ et : remplacés par -).
• Inbox entrante (que je lis) : inbox-from-<expéditeur>.md dans ma mémoire.
• Inbox sortante (où j'écris) : inbox-from-<moi>.md dans la mémoire du destinataire.
• Numérotation des messages : # 📨 #N — <expéditeur> → <destinataire> (<date>).

⚠️ Hétérogénéité des formats d'en-tête (dette doc à harmoniser). Trois conventions coexistent aujourd'hui dans les inboxes :

1. Numéroté niveau 1 : # 📨 #N — … (cible canonique ci-dessus ; codexia ↔ doc récent).
2. Numéroté niveau 2 : ## # 📨 #N — … (variante observée codexia ↔ doc).
3. Daté sans #N : ## AAAA-MM-JJ — … (sans emoji ; doc → tlr-mcp, et tlr-embeddings qui assume ce format — déjà noté dans son entrée).

Conséquence : tout outil qui lit les inboxes (ex. tlr inbox côté telaria-claude) doit gérer les trois. Cible : converger vers le format 1. Chantier d'harmonisation à planifier (non bloquant). Constaté 2026-05-30.

Dépôts actifs

1. telaria-app — application Symfony (ex-codexia, ex-telaria) · marque/produit assemblé

Repo GitHub renommé telaria → telaria-app (2026-06-07). Instance : Lead Tech Telaria (à onboarder) — Opus. ⚠️ État prod au 2026-06-15 : régression MEP (assets ❌, mail ❌, ChatbotConfig ❌ 500) — rétablissement = priorité n°1.

2. telaria-doc — documentation, specs, pilotage (ce dépôt, ex-codexia-doc)

Repo GitHub renommé codexia-doc → telaria-doc (2026-06-06, Batch 2, redirection active) ; migration filesystem terminée : dossier local C:\src\telaria-doc et dossier mémoire C--src-telaria-doc en place, skills wakeup/sync/pwp repointés. L'instance Claude est désormais « telaria-doc » / Atlas (Doc Lead) ; seul le fichier d'inbox sortant inbox-from-doc.md ne change pas (expéditeur = « doc »). Historique de l'opération : migration-batch2-telaria-doc.md.

3. tlr-embeddings — microservice Python /embed /health (ex-telaria-embeddings)

4. tlr-rag — bundle Symfony cœur RAG (L0) (ex-telaria-rag)

→ tlr-rag est un artefact piloté par codexia, pas une instance autonome. Aucune synchro directe à faire avec lui ; passer par codexia.

5. tlr-mcp — bundle Symfony serveur MCP (L1) (ex-telaria-mcp)

→ Bundle Symfony avec instance Claude dédiée (Sonnet) suite à la règle « 1 dépôt = 1 instance ». Pilote technique = codexia ; coordination passe aussi directement par doc via les canaux inboxes. Statut actuel : instance non vivante (clone+mémoire supprimés, Batch 1) — sera ré-onboardé sous tlr-mcp le jour venu.

6. tlr-symfony — bundle Symfony socle générique multi-domaines (L0)

→ tlr-symfony est un artefact piloté par codexia (issu du split Batch 3 / Phase 1), pas une instance autonome : pas de canal inbox (absent de la matrice ci-dessous). Phase 2 = bundle produit tlr-codexia — extrait & en prod (voir section 7).

⚠️ Socle obligatoire pour tout nouveau projet Symfony Telaria. Voir section Fondations en tête de ce document.

7. tlr-codexia — bundle Symfony produit doc-IA (L2)

→ tlr-codexia est un artefact piloté par codexia (split Batch 3 / Phase 2), pas une instance autonome : pas de canal inbox (absent de la matrice ci-dessous), comme tlr-rag et tlr-symfony. Avec son extraction, l'app telaria devient mince (User/auth + surface + CMS-front).

8. tlr-blueprint — repo de direction (Chef)

→ tlr-blueprint est l'espace de travail du Chef — deuxième autorité de l'écosystème. Le canon documentaire reste chez telaria-doc (Atlas).

9. adoption-app — application Symfony standalone (adoption IA)

10. adoption-corpus — corpus RAG documentaire (adoption IA)

→ adoption-corpus est le territoire éditorial du Rédacteur web, supervisé par Atlas pour la forme et l'optimisation IA. Le contenu est produit par le Rédacteur web + Lead Tech Adoption ; Atlas garantit la qualité d'ingestion. Pas de canal inbox actif.

11. adoption-doc — documentation produit Adoption IA (à venir)

→ adoption-doc sera onboardé après l'instance Chef. Atlas en est le gardien au même titre que telaria-doc.

12. tlr-memory — backup outillage IA (mémoires Claude + settings)

→ tlr-memory est un repo de persistance d'outillage IA, pas un bundle applicatif. Alimenté par backup-memory.ps1 (dans tlr-claude). Pas de canal inbox, pas d'instance Claude.

13. tlr-ansible — IaC infrastructure (poseidon + VPS OVH)

→ Repo IaC sans instance Claude. Piloté par Mathieu lors des interventions infra ; le Chef arbitre les décisions d'architecture réseau/hébergement.

14. tlr-vhosts — vhosts Apache versionnés (source unique)

→ Artefact infra sans instance Claude. Consommé par tlr-ansible pour le déploiement.

15. tlr-agents — CLI shell de l'écosystème (tlr)

→ Artefact outillage sans instance Claude dédiée. Développé et maintenu par Atlas.

16. tlr-claude — environnement de travail Claude (setup + skills + backup)

→ Repo méta-outillage. Pas de produit Telaria, pas d'instance Claude dédiée. Développé par Atlas.

17. tlr-cli — CLI Bash d'administration serveur (tlr)

→ Outil en production sur le VPS OVH. Pas de canal inbox, pas d'instance Claude dédiée.

⚠️ Dettes de renommage (2026-06-16) :

• README dit encore telaria-bash (ancien nom du repo) — à mettre à jour
• AGENTS.md pointe vers C:\src\telaria-bash (ancien chemin local) — à corriger en C:\src\tlr-cli
• Branche par défaut GitHub = master ; branche develop existe en remote — à aligner (switcher default → develop)

18. tlr-doc — espace de travail Atlas

→ tlr-doc est le carnet de travail versionné d'Atlas. Même rôle que tlr-blueprint pour le Chef. Invisible du RAG (hors scope ingestion). Atlas y travaille depuis C:\src\tlr-doc mais continue à livrer dans telaria-doc et adoption-doc.

Matrice des canaux

Canal tlr-blueprint ↔ telaria-doc actif depuis le 2026-06-14. embeddings ↔ mcp non prévu. Canaux telaria-app ↔ tlr-blueprint à ouvrir lors de l'onboarding du Chef.

⏸️ Canaux tlr-embeddings/tlr-mcp en sommeil depuis le Batch 1 (2026-06-05) : clones et mémoires supprimés (doctrine cattle). Inboxes reçues côté telaria-doc conservées comme historique. Réactiver au ré-onboarding.

Voir aussi

• Skill : C:\Users\mathi\.claude\skills\sync\SKILL.md
• Plan global : mémoire synchro-inter-instances (côté telaria-doc).
• Format inbox de référence : memory\inbox-from-codexia.md.