Conception système

Comment l’architecture maintient ses limites

Un système de production se définit autant par ce qu’il refuse que par ce qu’il accepte. Le travail reste central dans le navigateur, tandis que l’exécution, les secrets, les dépôts et l’autorité des processus restent sur le nœud choisi.

Plans de contrôle

Supervised node

Un service supervisé par utilisateur gère l’authentification de l’appareil, la politique locale et le tunnel sortant.

Typed WSS broker

Le broker multiplexe des trames typées de contrôle, terminal, diff et décision ; ce n’est pas un proxy TCP générique.

Detached workspaces

Chaque tâche de dépôt obtient un worktree Git détaché ; les autres tâches utilisent un espace privé.

Cycle d’une requête

authenticated CLI or browser request
  → typed broker envelope
  → target-owned policy decision
  → detached Git worktree or scratch space
  → bounded process and tmux session
  → sequenced events and reviewed receipt

Modèle de défaillance

Toute requête mal formée, périmée, surdimensionnée, non autorisée ou hors séquence est refusée avant le workspace ; la reprise reste bornée et idempotente.

Liste de vérification

Default deny: Une entrée cloud n’accorde jamais une autorité sur les fichiers ou les exécutables.
No inbound node port: Le nœud n’ouvre aucun port Bernato entrant ; l’IDE local écoute uniquement sur le loopback numérique.
Bounded execution: Les sous-processus ont des exécutables explicites, une durée bornée et une admission fermée en cas d’erreur.
Non-executable memory: Le Markdown suivi par Git est une référence non fiable, jamais une instruction exécutable.

← Retour à la présentation