Architecture
État architectural
Description synthétique de l'état courant du projet : ce qui est public, ce qui ne l'est pas, et comment les éléments disponibles s'articulent.
I. Principes
Principes structuraux
Le projet ne se présente pas sous la forme d'un système unique entièrement public. Il faut distinguer le site public, FridaDev comme dépôt applicatif public et Frida_V4 comme travail en cours non public. Les principes ci-dessous servent à maintenir la cohérence de cette description.
Cette cohérence vaut aussi pour la doctrine technique du projet : le pipeline y est traité comme le lieu d'une rencontre entre texte utilisateur, mémoire, documents, états intermédiaires et validation. L'architecture a pour tâche de rendre cette rencontre explicite, distribuée et révisable.
| Principe | Description |
|---|---|
| Statut public explicite | Le site doit distinguer ce qui est public, ce qui ne l'est pas et ce qui n'est public que sous forme documentaire isolée. |
| Statuts distincts des matériaux | Une trace, un résumé, un snippet récupéré, un document injecté, un log opérateur ou un document de recherche n'ont pas le même rôle. |
| Décomposition modulaire | Lorsque le projet décrit un runtime, il décrit des responsabilités séparées autant que possible : orchestration, mémoire, résumés, récupération, validation, documents, LLM, outillage local. |
| Rencontre codée dans le pipeline | Le prompt utilisateur est traité comme un texte, et le pipeline comme l'espace technique où s'organisent mémoire, temporalité, validation et révision. |
| Persistance et streaming décrits | Les conditions de persistance canonique et les contrats de streaming font partie de la description du système. |
| Observabilité | Les journaux, audits, surfaces d'administration et états de persistance doivent être décrits comme des éléments de l'architecture. |
| Évaluation avant affirmation | Le site ne doit pas attribuer à un module des propriétés qui ne seraient pas soutenues par le code, les documents ou les évaluations disponibles. |
II. Organisation
Couches et modules
Les éléments actuellement mentionnés sur le site peuvent être ordonnés de la manière suivante : un site public de documentation, un dépôt applicatif public, un dépôt applicatif non public et quelques documents publics portant sur des modules ou des problèmes de travail.
| Module | Fonction principale | État |
|---|---|---|
| FridaDev | Dépôt public. Runtime web en Python/Flask, chat navigateur, mémoire, branche herméneutique, streaming, persistance canonique et surfaces d'administration. | actif |
| Frida_V4 | Travail en cours non public. Runtime natif macOS en Swift, organisé par modules, avec mémoire, documents, voix, TTS et outillage local. | non public |
| frida-ai | Site public bilingue. Fonction actuelle : description du projet, index des documents publics, distinction des statuts de disponibilité. | en ligne |
| M6 Stimmung | Module de travail associé à Frida_V4. Le papier M6 est public sur ce site; le code et le dépôt de rattachement ne le sont pas à ce jour. | papier public |
| Documents publics | Audits, cartographies runtime, contrats de streaming, références d'exploitation et article de travail. | actif |
III. Invariants
Invariants du système
Les invariants suivants servent ici à décrire la manière dont le site doit parler du projet.
- Le site distingue systématiquement ce qui est public, ce qui ne l'est pas et ce qui n'est public que sous forme documentaire.
- Le site ne présente pas comme accessible un dépôt ou un module qui ne l'est pas.
- Trace, résumé, document injecté, snippet récupéré, signal de jugement et log d'exécution ne sont pas confondus dans la description.
- Un signal dialogique ou herméneutique n'est pas présenté comme une preuve en soi.
- Les contrats de persistance et de streaming sont traités comme des éléments d'architecture à part entière.
- Les surfaces d'observabilité et d'administration sont décrites lorsqu'elles existent effectivement dans le dépôt public.
- Le site n'attribue pas au projet une unité logicielle fictive alors que ses éléments ont des statuts différents.
- Les affirmations fortes sur un module doivent pouvoir être rapportées à un document, un dépôt ou une évaluation disponible.
- Les métriques éventuelles ne remplacent pas la lecture située du dialogue; elles l'accompagnent.
IV. Tensions et questions ouvertes
Problèmes en cours d'exploration
Les questions suivantes restent ouvertes dans le projet.
- Passage entre dépôt public et travail non public. Comment décrire les continuités entre FridaDev et Frida_V4 sans laisser entendre une disponibilité publique identique ?
- Évaluation de M6. Comment mesurer l'effet d'un module de régime dialogique sur la cohérence, la révision et la non-surinterprétation ?
- Critère exégétique. Comment articuler une lecture qualitative du dialogue avec des métriques locales sans réduire la validité du système à une seule famille d'indicateurs ?
- Mémoire et documents. Comment articuler mémoire, résumés et documents injectés sans confusion de statut ?
- Voix, outils locaux, sécurité. Comment décrire et évaluer les capacités non publiques liées à la voix ou à l'outillage local lorsqu'elles ne sont pas encore ouvertes ?
- Publication. Comment rendre public un article ou un document sur un module dont le dépôt d'origine n'est pas encore ouvert ?