Contratto delle azioni e delle capacità
Distinguere scoperta delle azioni, rapporti delle capacità installate, controllo preliminare, esecuzione e autorità server.
Panoramica
La CLI fornisce un manifesto delle azioni, controllo preliminare offline, scoperta delle capacità installate e comandi nativi espliciti. Il bootstrap 0.1.9 crea la struttura installata firmata necessaria per le capacità. Questi output rispondono a domande diverse; nessuno deve essere considerato una prova degli altri.
Manifesto delle azioni cliente
Il manifesto versionato contiene 25 azioni:
22 azioni sono contrassegnate
executes=true;altifigence.analyze.run,altifigence.evolve.launchealtifigence.verify.runsono le tre azioni di sola pianificazione.
executes=true significa che l'azione è definita come eseguibile. Il comando effettivo può comunque richiedere un motore locale, autorizzazioni dell'account o un servizio remoto. Un'azione di sola pianificazione valida e restituisce un piano senza eseguire un job.
Usare alti commands per esaminare il manifesto distribuito con il binario corrente. Non copiare un elenco di comandi da una release diversa.
Ricevuta del controllo preliminare offline
Il flusso offline job validate verifica un involucro RTL CPU limitato e un sorgente sicuro relativo all'area di lavoro. Una ricevuta riuscita dichiara esplicitamente submitted: false e server_authority_verified: false. Non esegue un motore locale né contatta un servizio ospitato. Vedere Prima esecuzione riuscita con la CLI.
Contratto delle capacità dei motori installati
Lo schema delle capacità definisce questi stati per una release correttamente installata e comprovata da ricevute:
Stato | Significato |
|---|---|
| La release installata fornisce l'interfaccia locale documentata |
| È disponibile soltanto il sottoinsieme riportato |
| La release installata non può fornire l'interfaccia |
| L'interfaccia richiede un consenso esplicito e documentato |
| L'azione restituisce un piano anziché una prova di esecuzione |
Seguire Verifica dei download e Installazione su Linux prima di usare alti capabilities. Il bootstrap incorporato crea la struttura autenticata di catalogo/ricevute; non copiare un binario altrove né fabbricare tale stato. La disponibilità installata descrive le capacità disponibili. La prova dell'esecuzione di un progetto o job GPU proviene dal relativo risultato di esecuzione.
Domanda | Risposta fornita da |
|---|---|
Questo comando è stato eseguito qui e con quale risultato? | Lo stato di uscita del comando e la riga della ricevuta che indica binario, risoluzione e stato |
Questa release installata dichiara disponibile la capacità? | Un rapporto riuscito di |
Un comando locale riuscito riporta ciò che è stato eseguito su quella macchina. Un'automazione che dipende da una capacità del prodotto installato deve richiedere anche il rapporto delle capacità.
Il caricamento dei sorgenti richiede consenso
Nella modalità cliente predefinita, il server MCP stdio incluso nasconde le tre azioni di pianificazione che possono includere file sorgente. Richiedono credenziali di ambiente separate e usano il client Cloud. La release pubblica corrente non fornisce per loro un flusso completo di esecuzione remota.
La modalità separata ALTI_MCP_MODE=local-xls espone strumenti XLS locali fissi senza inoltro Cloud. Le operazioni native ide cloud usano regole proprie di accesso e caricamento esplicito; lo stato delle azioni cliente di sola pianificazione non descrive tutte le operazioni dell'area di lavoro Cloud.
Il consenso permette la trasmissione; non trasforma un'azione di sola pianificazione in una vera esecuzione né rende disponibile un servizio remoto.
Gestire ogni risultato separatamente
Quando si automatizza la CLI, gestire questi risultati come stati diversi:
una capacità locale è disponibile;
una richiesta è stata validata;
è stato restituito un piano senza esecuzione;
il lavoro è stato accettato da un'autorità esplicitamente abilitata;
il lavoro è stato completato e ha prodotto prove;
una capacità o autorità non era disponibile.
Ridurre questi stati a un unico valore di successo può far apparire un piano o un'anteprima come lavoro ingegneristico completato.
Selezionare il contratto di risultato corretto
Per un'esecuzione locale, registrare motore selezionato, digest dell'input, stato di uscita nativo e risultato completo. Per una modifica di file salvato, conservare piano e ricevuta di applicazione e rileggere il file. Per un job remoto, seguirne l'ID fino allo stato finale, poi recuperare e verificare il risultato effettivo. Una voce del manifesto delle azioni descrive soltanto l'interfaccia invocabile.
Mantenere distinti nell'automazione gli involucri di richiesta dei motori locali, le azioni di pianificazione cliente e i job RTL Cloud salvati. Differiscono per schema di input, posizione del sorgente, autenticazione, invio e gestione dei risultati anche quando i loro nomi contengono “analyze” o “evolve”.