Architettura

Processi e confini della fiducia

Tauri possiede l'integrazione nativa delle finestre, comandi di credenziali sicure, menu, aggiornamenti e ciclo di vita sidecar. La sua visualizzazione web esegue l'applicazione SolidJS. Il sidecar Bun compilato apre il database e serve HTTP 127.0.0.1 con una porta assegnata dal sistema operativo. Il frontend non apre SQLite.

Il punto di ingresso del sidecar è apps/sidecar/src/main.ts. Crea il server HTTP, costruisce i livelli dell'applicazione, sonda /api/health, quindi stampa un evento di disponibilità JSON contenente la porta scelta. I log vengono instradati a stderr in modo che stdout rimanga disponibile per il protocollo della shell.

Il compagno mobile raggiunge un gateway desktop accoppiato esplicitamente. Le credenziali native del dispositivo e del trasporto sono separate dalla connessione loopback della visualizzazione Web desktop. La documentazione Worker è una distribuzione separata e non ha alcuna connessione implicita al desktop dell'utente.

Dipendenze della libreria

@cadcamfun/core contiene calcoli CAD, disegni e CAM. Dipende dall'Effetto per gli schemi e l'integrazione dei confini; i cicli algoritmici sono normali TypeScript. @cadcamfun/api importa tipi e schemi principali per dichiarare input, output, errori e flussi HTTP.

@cadcamfun/db possiede il servizio del database dell'applicazione, lo schema e la logica di migrazione. Il sidecar lo combina con pacchetti core, API, AI, plug-in SDK, VCS e flussi di lavoro. I suoi repository utilizzano il servizio database; i gestori delegano a repository e servizi.

Il desktop importa entrambi @cadcamfun/api e @cadcamfun/core. Utilizza l'API in fase di esecuzione tramite un client Effect e utilizza la geometria principale nelle funzionalità CAD/CAM e nel viewport. Il dispositivo mobile dipende dal pacchetto API e racchiude le richieste complementari nel proprio client. Il plug-in nikcli autonomo rileva il catalogo delle azioni dell'applicazione in esecuzione su HTTP anziché importare implementazioni di backend.

Ciclo di vita della richiesta HTTP

1. La webview ottiene la connessione sidecar dalla shell nativa.
2. apps/desktop/src/app/client.ts crea un client Effect HttpApi con autorizzazione al portatore e un token di sessione dell'account opzionale. packages/api/src/client.ts fornisce un cliente contrattuale riutilizzabile per altri consumatori.
3. apps/sidecar/src/layers.ts assembla ServedApi, gestori, autorizzazione, CORS e livelli di servizio condiviso.
4. Il gestore convalida gli input del contratto, risolve i servizi, esegue calcoli o persistenza e restituisce la rappresentazione di successo o errore dichiarata. Gli endpoint di streaming mantengono il protocollo di streaming dichiarato.

CORS consente origini di produzione Tauri e origini di loopback HTTP utilizzate nello sviluppo. Non sostituisce l'autorizzazione. L'API espone diversi stili di busta di risposta; i consumatori devono seguire lo schema di ciascun endpoint anziché presumere che ogni risposta abbia la stessa forma.

Ciclo di vita e archiviazione del servizio

I livelli di effetti acquisiscono il database e i servizi condivisi nell'ambito dell'applicazione. Il livello del database crea la propria directory padre, abilita WAL e chiavi esterne, applica facoltativamente le migrazioni e racchiude gli errori di query con un nome di operazione. La finalizzazione tenta di troncare il checkpoint WAL e chiude l'handle SQLite.

Il DatabaseLive il livello seleziona dataDir/cadcamfun.db. È necessario fornire una cartella di migrazione per applicare le migrazioni all'avvio. Le credenziali AI, lo stato del plug-in, gli oggetti VCS, l'esecuzione del flusso di lavoro e l'archiviazione dei file vengono gestiti tramite le rispettive interfacce di servizio; i dettagli di archiviazione sono descritti nelle pagine dei moduli.

Lo Studio locale in packages/web/script/studio-server.ts è un processo Bun aggiuntivo. Apre direttamente un database dell'applicazione esistente configurato e fornisce dati generali autenticati sulla porta di loopback 4396. Il suo proxy di sviluppo e le sessioni dei cookie sono indipendenti dalla connessione sidecar Tauri.

Gli eventi del progetto in tempo reale (richieste pull, commit, esecuzioni del flusso di lavoro e fasi della sessione dell'assistente) vengono pubblicati tramite un servizio eventi in-process. Un nuovo iscritto riceve prima fino a 20 eventi corrispondenti più recenti e poi quelli live, facoltativamente filtrati per progetto e tipo di evento (apps/sidecar/src/services/live-events.ts).

Confini dell'estensione

Esistono due integrazioni di plug-in. L'SDK del plug-in dell'applicazione definisce manifest, funzionalità, attivazione e contratti host. Il bridge nikcli espone le azioni CAD/CAM registrate a un assistente esterno. L'installazione di un plug-in tramite un percorso del registro HTTP è un'operazione separata dall'attivazione di un modulo nell'host runtime.

L'analisi e la pianificazione del flusso di lavoro sono attive packages/workflow. I passaggi supportati dal servizio vengono registrati dai livelli sidecar, mentre i passaggi puramente di progetto e CAM possono essere eseguiti con gli input forniti. VCS calcola gli hash degli oggetti, le differenze, le unioni e le operazioni di trasporto GitHub nella sua libreria; i servizi collaterali collegano tali operazioni alla persistenza del progetto.

L'assistente alla documentazione Web recupera la documentazione sottoposta a rendering e può pubblicare elementi guida quando viene configurata l'archiviazione. Risponde alle domande sulla documentazione; non eredita l'accesso al progetto locale dell'applicazione CAD/CAM.

Connessione e confini delle credenziali

L'autorizzazione è stratificata. Il passaggio del middleware portatore non dimostra la proprietà di un particolare disegno o progetto; gestori e repository controllano tali risorse. L'accoppiamento in modo simile non trasforma il telefono in un client sidecar senza restrizioni. Consultare l'endpoint specifico e la policy complementare prima di scegliere una credenziale.

L'adattatore di autorizzazione è apps/sidecar/src/http/authorization.ts. Le decisioni del compagno e del ponte vivono nei propri servizi. Mantenere questi percorsi separati consente di revocare un dispositivo smarrito o un token di integrazione senza sostituire il segreto di un provider di intelligenza artificiale.

Isolamento dei guasti

Gli errori prima dell'evento di disponibilità appartengono all'inizializzazione del sidecar: configurazione, aggiornamento del database, costruzione del servizio o avvio HTTP. Gli errori successivi alla preparazione possono essere specifici di un provider, di un'operazione del file system, di un endpoint o di una sessione client. Il ciclo di vita della shell e il budget dei tentativi di connessione della visualizzazione web sono distinti; ispezionarli entrambi quando un riavvio cambia la porta di ascolto.

Un flusso AI disconnesso non interrompe necessariamente la conversazione lato server. Ripristina lo stato della sessione prima di inviare nuovamente un'istruzione di modifica. Un flusso di lavoro non riuscito non ripristina il commit di attivazione. Un push remoto non riuscito non cancella la cronologia locale. Queste distinzioni impediscono che un errore di rete venga gestito come se un'operazione persistente non si fosse mai verificata.

Per una richiesta API con esito negativo, registra il metodo, il percorso, lo stato, l'ID dell'endpoint e gli identificatori non segreti pertinenti. Confronta la corsa /api/openapi.json con il istantanea del contratto di documentazione quando le versioni client e server differiscono. Evita la risoluzione dei problemi con un token di un precedente lancio del sidecar.

Snapshot dell'architettura per percorso di origine

Traccia: dal lancio alla prima richiesta

1. Tauri inizia ed entra il supervisore sidecar.rs genera un token casuale.
2. Si genera sidecar-<triple> con CADCAMFUN_TOKEN, CADCAMFUN_DATA_DIR e CADCAMFUN_MIGRATIONS_DIR.
3. Il sidecar legge la sua configurazione, apre SQLite (WAL, chiavi esterne), esegue il backup e la migrazione se necessario e crea i suoi livelli di servizio.
4. Si lega 127.0.0.1 su una porta temporanea e stampa una riga pronta per JSON su stdout. Il supervisore attende fino a 60 s.
5. Il supervisore emette sidecar-status { state: "ready", port }; le chiamate della visualizzazione web get_sidecar_endpoint per { baseUrl, token }.
6. La visualizzazione web viene creata ApiClient.layer({ baseUrl, token }) e inizia a caricare i progetti.

Se il sidecar esce, il supervisore lo riavvia una volta e annuncia la nuova porta; un secondo fallimento lascia lo stato a failed. All'uscita, il supervisore scrive la riga di spegnimento, attende 2 se poi riprende il processo; il livello del database controlla il WAL quando il suo ambito si chiude.

Traccia: una richiesta di produzione

1. L'area di lavoro CAM acquisisce gli elementi del disegno, lo stock e le chiamate POST /api/toolpaths/manufacture.
2. Il middleware portante ammette la richiesta; il corpo viene decodificato CamKernelRequest.
3. runKernelRequest in services/cam-program.ts chiamate cam.kernel.jobOfSnapshot; i problemi di preparazione diventano un 400.
4. cam.kernel.runJob pianifica o segue le operazioni, calcola i dati di taglio, genera percorsi utensile, pubblica NC per il dialetto della macchina e lo riproduce su stock voxel per valutare le richieste.
5. Il risultato viene decodificato CamKernelResult e restituito. Nulla viene archiviato finché il client non salva un percorso utensile con un documento portatile, a quel punto il sidecar riesegue la richiesta acquisita e la confronta.

Nel 3D