Arquitectura

Direkte Antwort

Wie Astro-, Phoenix-, Neon-, Oban- und Herstelleradapter in der aktuellen Alpha-Version von TextTree passen.

Seiteninhalt

# Architektur

Die öffentliche Site und die Anwendungsausführungsumgebung sind bewusst getrennt.

## Öffentliche Oberfläche

Astro ist verantwortlich für:

- Zielseiten
- Dokumentation
- Blog
- SEO-Metadaten, RSS- und Sitemap-Generierung

## Anwendungsfläche

Phoenix ist verantwortlich für:

- Login und Authentifizierung Benutzererfahrung
-`/api/v1/*` 
- signierte Webhooks von Anbietern
-`/mcp/*` 

## Zentralstaat

Postgres powered by Neon ist das Aufzeichnungssystem für:

- Native Phoenix-Benutzer und TextTree-Authentifizierungsidentitäten
- Headless-Agentenkonten basierend auf dem Benutzernamen
- Benutzer und Arbeitsbereiche
- Geerbte Einwilligungs-/Kontaktmetadaten
- Löschungen von Arbeitsbereichen und Kampagnen
- Nachrichten
- Hauptbucheinträge und Ausgabenlimits
- Lieferantenveranstaltungen
-Finanzierungssitzungen
- MCP-Ausführungsprüfungen

## Verantwortung der Arbeitnehmer

Oban ist für Nebenwirkungen und Wiederholungsversuche verantwortlich.

- Ausgehende Nachrichten werden vor der Ausführung beim Provider in die Warteschlange gestellt
- Lieferantenereignisse werden vor dem Abgleich gespeichert
- Wiederholungs- und Wiederholungspfade werden von Controllern und LiveViews ferngehalten

## Ausführungsregeln

Ausgehende Nachrichten folgen einem stärkeren Weg:

1. Überprüfung der Löschung des Arbeitsbereichs
2. Spesenrücklage und Eintragung in das Rechnungsbuch
3. Kleben in Oban
4. Ausführung beim Anbieter innerhalb eines Arbeitnehmers

Dadurch werden externe Nebenwirkungen von Controllern und LiveViews ferngehalten.

## Webhook-Regeln

Anbieter-Webhooks folgen einer parallelen Grenze:

1. Signaturüberprüfung
2. normalisierte Ereignispersistenz
3. Duplikaterkennung
4. Kleben in Oban
5. Abgleich im Nachrichten-, Lösch- oder Finanzierungsstatus

## MCP-Regeln

Der MCP-Footprint ist in der Alpha-Version gezielt reduziert:

1. Bootstrap für öffentliche Gesundheit und Headless-Konten
2. TextTree-Bearer-Token-Authentifizierung für Werkzeugpfade
3. Anwendung von Bereichen auf Routenebene
4. Serverregistrierung und Zulassungslistenprüfungen
5. Quoten- und Wartezeitkontrolle
6. Ständige Ausführungsüberwachungsprotokolle

Bootstrap-Headless-Inhalte über `/api/v1/accounts` oder `/mcp/accounts` erstellen
ein Agentenkonto mit Benutzername/Passwort, einmaligen Backup-Codes und einem Token-Inhaber
von TextTree. Die Bootstrap-Beschränkung speichert eine gespeicherte IP-Adresse und lässt nur eine zu
Erfolgreiche Kontoerstellung pro IP alle fünf Minuten.

## Lieferantengrenzen

Controller und LiveViews rufen Anbieter nicht direkt an.

- Messaging-Routen kommunizieren mit dem Messaging-Kontext
- Finanzierungswege kommunizieren mit dem Finanzierungskontext
– Die anbieterspezifische HTTP-Semantik wird in den Anbieteradaptern verwaltet
– Die Webhook-Normalisierung erfolgt vor dem Abgleich des Geschäftsstatus

## Einschränkungen der Alpha-Version

Diese Architektur ist bereits nutzbar, bleibt aber bewusst unvollständig:

– Die lokalen ADRs des Repositories erfassen die aktuelle Bereitstellungsbasislinie, während der kanonische Canvas-Import noch aussteht
- Einige Produktoberflächen sind nur für Betreiber und nicht für öffentliche API-Verträge bestimmt
– MCP-Tools werden mit dem konfigurierten Server verwendet und nicht von Mandant bereitgestellt
- Die Dokumentation beschreibt den implementierten Alpha-Vertrag, kein Versprechen einer zukünftigen Roadmap