Architecture

Réponse directe

Comment les adaptateurs Astro, Phoenix, Neon, Oban et les fournisseurs s'intègrent dans la version alpha actuelle de TextTree.

Contenu source

# Architecture

Le site public et l’environnement d’exécution des applications sont volontairement séparés.

## Surface publique

Astro est responsable de :

- pages de destination
-documentation
-blog
- Génération de métadonnées SEO, RSS et sitemap

## Surface d'application

Phoenix est responsable de :

- connexion et expérience utilisateur authentifiée
-`/api/v1/*`
- webhooks signés par les fournisseurs
-`/mcp/*`

## État central

Postgres propulsé par Neon est le système d'enregistrement pour :

- Utilisateurs natifs Phoenix et identités d'authentification TextTree
- comptes d'agent sans tête basés sur le nom d'utilisateur
- les utilisateurs et les espaces de travail
- métadonnées héritées du consentement/des contacts
- suppressions d'espaces de travail et de campagnes
- messages
- écritures comptables et limites de dépenses
- événements fournisseurs
- séances de financement
- Audits d'exécution MCP

## Responsabilité des travailleurs

Oban est responsable des effets secondaires et des tentatives.

- les messages sortants sont mis en file d'attente avant exécution chez le fournisseur
- les événements fournisseurs sont stockés avant rapprochement
- les chemins de répétition et de nouvelle tentative sont tenus à l'écart des contrôleurs et des LiveViews

## Règles d'exécution

La messagerie sortante suit un itinéraire strict :

1. vérification de la suppression de l'espace de travail
2. réserve de dépenses et inscription dans le livre comptable
3. collage à Oban
4. exécution chez le fournisseur à l'intérieur d'un travailleur

Cela évite les effets secondaires externes des contrôleurs et des LiveViews.

## Règles des webhooks

Les webhooks du fournisseur suivent une limite parallèle :

1. vérification de la signature
2. persistance normalisée des événements
3. détection des doublons
4. collage à Oban
5. rapprochement dans le message, la suppression ou l'état de financement

## Règles MCP

La surface de MCP est volontairement réduite dans la version alpha :

1. Bootstrap pour la santé publique et les comptes sans tête
2. authentification avec le jeton porteur TextTree pour les parcours d'outils
3. application des périmètres au niveau de l'itinéraire
4. Enregistrement du serveur et vérifications de la liste blanche
5. Contrôles des quotas et des temps d'attente
6. Journaux d'audit d'exécution persistants

Les comptes sans tête Bootstrap via `/api/v1/accounts` ou `/mcp/accounts` créent
un compte d'agent avec nom d'utilisateur/mot de passe, des codes de sauvegarde à usage unique et un porteur de jeton
par TextTree. La limitation d'amorçage stocke une adresse IP hachée et n'en autorise qu'une seule.
Création de compte réussie par IP toutes les cinq minutes.

## Limites des fournisseurs

Les contrôleurs et LiveViews n’appellent pas directement les fournisseurs.

- les routes de messagerie communiquent avec le contexte de messagerie
- les itinéraires de financement communiquent avec le contexte de financement
- La sémantique HTTP spécifique au fournisseur est conservée dans les adaptateurs de fournisseur
- la normalisation du webhook a lieu avant la réconciliation de l'état de l'entreprise

## Restrictions de la version Alpha

Cette architecture est déjà utilisable, mais reste volontairement incomplète :

- les ADR locaux du référentiel capturent la ligne de base de déploiement actuelle alors que l'importation canonique du canevas est toujours en attente
- certaines surfaces de produits sont réservées aux opérateurs et non aux contrats publics API
- Les outils MCP sont configurés sur le serveur, et non par locataire
- la documentation décrit le contrat alpha mis en œuvre, et non les promesses d'une future feuille de route