Architecture

Processus et limites de confiance

Tauri possède l'intégration native des fenêtres, les commandes d'informations d'identification sécurisées, les menus, les mises à jour et le cycle de vie du sidecar. Sa vue Web exécute l'application SolidJS. Le sidecar Bun compilé ouvre la base de données et sert HTTP sur 127.0.0.1 avec un port attribué par le système d'exploitation. Le frontend n'ouvre pas SQLite.

Le point d'entrée du sidecar est apps/sidecar/src/main.ts. Il crée le serveur HTTP, construit les couches d'application, sonde /api/health, puis imprime un événement de préparation JSON contenant le port choisi. Les journaux sont acheminés vers stderr afin que stdout reste disponible pour le protocole shell.

Le compagnon mobile atteint une passerelle de bureau explicitement couplée. Ses informations d'identification natives de transport et de périphérique sont distinctes de la connexion de bouclage de la vue Web du bureau. Le Documentation Worker est un déploiement distinct et n'a aucune connexion implicite au bureau d'un utilisateur.

Dépendances de la bibliothèque

@cadcamfun/core contient des calculs de CAO, de dessin et de FAO. Cela dépend d'Effet pour les schémas et l'intégration des limites ; les boucles algorithmiques sont du TypeScript ordinaire. @cadcamfun/api importe les types de base et les schémas pour déclarer les entrées, sorties, erreurs et flux HTTP.

@cadcamfun/db possède le service de base de données d'application, le schéma et la logique de migration. Le sidecar le combine avec des packages de base, d'API, d'IA, de plug-in SDK, VCS et de workflow. Ses référentiels utilisent le service de base de données ; les gestionnaires délèguent aux référentiels et aux services.

Le bureau importe les deux @cadcamfun/api et @cadcamfun/core. Il utilise l'API lors de l'exécution via un client Effect et utilise la géométrie de base dans les fonctionnalités CAO/FAO et la fenêtre. Mobile dépend du package API et encapsule les requêtes compagnon dans son client. Le plugin nikcli autonome découvre le catalogue d'actions de l'application en cours d'exécution via HTTP plutôt que d'importer les implémentations backend.

Cycle de vie des requêtes HTTP

1. La vue Web obtient la connexion sidecar à partir du shell natif.
2. apps/desktop/src/app/client.ts crée un client Effect HttpApi avec une autorisation du porteur et un jeton de session de compte facultatif. packages/api/src/client.ts fournit un client contractuel réutilisable pour d’autres consommateurs.
3. apps/sidecar/src/layers.ts assemble ServedApi, gestionnaires, autorisations, CORS et couches de services partagés.
4. Le gestionnaire valide les entrées du contrat, résout les services, effectue le calcul ou la persistance et renvoie la représentation du succès ou de l'erreur déclarée. Les points de terminaison de streaming conservent leur protocole de flux déclaré.

CORS autorise les origines de production Tauri et les origines de bouclage HTTP utilisées dans le développement. Elle ne remplace pas l'autorisation. L'API expose plusieurs styles d'enveloppe de réponse ; les consommateurs doivent suivre le schéma de chaque point de terminaison plutôt que de supposer que chaque réponse a la même forme.

Cycle de vie des services et stockage

Les couches d'effet acquièrent la base de données et les services partagés dans le cadre de l'application. La couche de base de données crée son répertoire parent, active les WAL et les clés étrangères, applique éventuellement des migrations et enveloppe les échecs de requête avec un nom d'opération. La finalisation tente un point de contrôle WAL tronqué et ferme le handle SQLite.

Le DatabaseLive sélection de calques dataDir/cadcamfun.db. Un dossier de migration doit être fourni pour appliquer les migrations au démarrage. Les informations d'identification IA, l'état du plugin, les objets VCS, l'exécution du flux de travail et le stockage de fichiers sont gérés via leurs interfaces de service respectives ; les détails de stockage sont décrits sur les pages de leurs modules.

Le studio local à packages/web/script/studio-server.ts est un processus Bun supplémentaire. Il ouvre directement une base de données d'application existante configurée et sert des données de présentation authentifiées sur le port de bouclage 4396. Son proxy de développement et ses sessions de cookies sont indépendants de la connexion sidecar Tauri.

Les événements de projet en direct (demandes d'extraction, validations, exécutions de flux de travail et phases de session d'assistant) sont publiés via un service d'événements en cours. Un nouvel abonné reçoit d'abord les 20 événements correspondants les plus récents, puis les événements en direct, éventuellement filtrés par projet et type d'événement (apps/sidecar/src/services/live-events.ts).

Limites d'extension

Il existe deux intégrations de plugins. Le SDK du plugin d'application définit les manifestes, les capacités, l'activation et les contrats d'hôte. Le pont nikcli expose les actions CAO/FAO enregistrées à un assistant externe. L'installation d'un plug-in via une route de registre HTTP est une opération distincte de l'activation d'un module dans l'hôte d'exécution.

Analyse et planification du flux de travail en direct packages/workflow. Les étapes basées sur des services sont enregistrées par des couches sidecar, tandis que les étapes de projet et CAM pures peuvent s'exécuter avec les entrées fournies. VCS calcule les hachages d'objets, les différences, les fusions et les opérations de transport GitHub dans sa bibliothèque ; Les services sidecar connectent ces opérations à la persistance du projet.

L'assistant de documentation Web récupère la documentation rendue et peut publier des artefacts de guide lorsque le stockage est configuré. Il répond aux questions de documentation ; il n'hérite pas de l'accès au projet local de l'application CAO/FAO.

Limites de connexion et d’informations d’identification

L'autorisation est superposée. Le passage du middleware porteur ne prouve pas la propriété d'un dessin ou d'un projet particulier ; les gestionnaires et les référentiels vérifient ces ressources. De même, le couplage ne transforme pas le téléphone en un client sidecar sans restriction. Consultez la politique spécifique du point de terminaison et du compagnon avant de choisir un identifiant.

L'adaptateur d'autorisation est apps/sidecar/src/http/authorization.ts. Les décisions relatives aux compagnons et aux ponts résident dans leurs propres services. Garder ces chemins séparés permet de révoquer un appareil perdu ou un jeton d'intégration sans remplacer le secret d'un fournisseur d'IA.

Isolation des pannes

Les échecs avant l’événement de préparation appartiennent à l’initialisation du sidecar : configuration, mise à niveau de la base de données, construction du service ou démarrage HTTP. Les échecs après la préparation peuvent être spécifiques à un fournisseur, à une opération de système de fichiers, à un point de terminaison ou à une session client. Le cycle de vie du shell et le budget de tentative de connexion de la vue Web sont distincts ; inspectez les deux lorsqu’un redémarrage modifie le port d’écoute.

Un flux IA déconnecté n’arrête pas nécessairement sa conversation côté serveur. Récupérez l’état de la session avant de renvoyer une instruction d’édition. Un workflow ayant échoué n'annule pas sa validation de déclenchement. Un push à distance infructueux n’efface pas l’historique local. Ces distinctions empêchent qu'une panne de réseau soit traitée comme si une opération persistante ne s'était jamais produite.

Pour une demande d'API ayant échoué, enregistrez sa méthode, son chemin, son statut, son ID de point de terminaison et ses identifiants non secrets pertinents. Comparez la course /api/openapi.json avec le instantané du contrat de documentation lorsque les versions client et serveur diffèrent. Évitez d'effectuer un dépannage avec un jeton d'un lancement précédent de sidecar.

Instantané d'architecture par chemin source

Trace : du lancement à la première requête

1. Tauri démarre et le superviseur entre sidecar.rs génère un jeton aléatoire.
2. Il apparaît sidecar-<triple> avec CADCAMFUN_TOKEN, CADCAMFUN_DATA_DIR et CADCAMFUN_MIGRATIONS_DIR.
3. Le sidecar lit sa configuration, ouvre SQLite (WAL, clés étrangères), sauvegarde et migre si nécessaire, et construit ses couches de service.
4. Il lie 127.0.0.1 sur un port éphémère et imprime une ligne prête JSON sur la sortie standard. Le superviseur attend jusqu'à 60 s.
5. Le superviseur émet sidecar-status { state: "ready", port }; la vue Web appelle get_sidecar_endpoint pour { baseUrl, token }.
6. La vue Web se construit ApiClient.layer({ baseUrl, token }) et commence à charger les projets.

Si le sidecar se ferme, le superviseur le redémarre une fois et annonce le nouveau port ; un deuxième échec laisse le statut à failed. À la fermeture, le superviseur écrit la ligne d'arrêt, attend 2 s, puis reprend le processus ; la couche de base de données vérifie le WAL à mesure que sa portée se termine.

Trace : une demande de fabrication

1. L'espace de travail CAM capture les éléments de dessin, le stock et les appels POST /api/toolpaths/manufacture.
2. Le middleware support accepte la demande ; le corps est décodé contre CamKernelRequest.
3. runKernelRequest dans services/cam-program.ts appels cam.kernel.jobOfSnapshot; les problèmes de préparation deviennent un 400.
4. cam.kernel.runJob planifie ou suit les opérations, calcule les données de coupe, génère des parcours d'outils, publie la CN pour le dialecte de la machine et la rejoue sur le stock de voxels pour évaluer les réclamations.
5. Le résultat est décodé par rapport CamKernelResult et revint. Rien n'est stocké jusqu'à ce que le client enregistre un parcours d'outil avec un document portable, auquel cas le sidecar réexécute la requête capturée et compare.

En 3D