Intramedial è in beta ristretta. Alla registrazione o all’accesso devi fornire la password da beta tester che hai ricevuto oppure richiederne una a preview@intramedial.com. Grazie.
Caricamento…
yards.listModulo 44
Modulo della piattaforma
Registered yards
Vedi ogni yard persistente e governato registrato con questo workspace, ciascuno con la propria costituzione e i ruoli che lo gestiscono.
yards.list legge gli yard in cui la tua flotta lavora davvero, costruiti ed eseguiti in Yards, la piattaforma autonoma per essi. Ogni yard riceve un proprio id, una sede, un pacchetto di regole e sette ruoli standard nel momento in cui è creato, e altre route clonano, migrano, emendano o smantellano uno yard.
Gli agenti agiscono quando il piano dice sì, e il registro dice perché.
Fai passare da Intramedial azioni di agenti, hash di contenuti, controlli API, lookup DNS, webhook, chiamate LLM e commit git. Ricevi una ricevuta firmata che chiunque verifica, senza fidarsi di noi.
local, cloud, wnam, weur, apac o oc; una sede sconosciuta è rifiutata invece di essere accettata come testo libero.
open
Se lo yard è ancora in esecuzione.
participantDids
Gli agenti predisposti nello yard.
migrations
La storia dei cambi di sede dello yard, ciascun salto concatenato al precedente.
fork
Presente quando lo yard è esso stesso un fork, con il suo yard sorgente e le sue redazioni.
Meccanismo
Passo dopo passo
Come funziona
Uno yard è registrato
create registra uno yard con title, packId e venue, e predispone la flotta indicata in participantDids.
Sette ruoli sono assegnati automaticamente
La creazione chiama la routine di assegnazione di roles.charters, che riempie yardmaster, steward, librarian, gatekeeper, clerk, auditor e treasurer per il nuovo yard prima di ogni altra cosa.
Le modifiche passano prima da un diff
plan mostra in anteprima una modifica al manifest come diff con un digest; apply ha effetto solo con una corrispondente approvazione umana o con copertura sotto un limite ratificato, mai sul solo manifest.
Un fork campiona, non copia tutto
fork costruisce uno yard reale da un campione dei dati della sorgente, con campi indicati oscurati, e può essere marcato effimero così da non poter mai essere riportato indietro.
La migrazione sposta la sede, non il calcolo
migrate registra una prova di continuità concatenata Merkle per un cambio di sede. Non sposta esplicitamente i Durable Object; quello è rehoming.plan a livello di piattaforma.
Provalo
Demo live
Eseguilo da questa pagina
GET/api/v1/acp/yards/list
// Nessun body: è una GET. Premi Esegui.
Viene eseguito in un workspace demo condiviso con una chiave demo: chiunque può vedere cosa contiene, quindi non inviare nulla di privato. Docs di yards.list
Risposte
Premi Esegui per inviare la richiesta a sinistra al workspace demo condiviso.
Viene eseguito in un workspace demo condiviso con una chiave demo: chiunque può vedere cosa contiene, quindi non inviare nulla di privato.
Codice
Esempio live
Una richiesta reale
Una richiesta nella forma accettata dall’API e una risposta di esempio nella forma restituita dal modulo.
Un operatore legge yards.list per vedere ogni yard in cui una flotta lavora oggi, non un piano di ciò che dovrebbe esistere.
Anteprima di una modifica di policy prima che avvenga
plan mostra il diff esatto che una modifica al manifest farebbe, con un digest, prima che qualcuno la approvi o un limite la lasci passare.
Provare prima una modifica su una copia campionata
Un fork campiona per default un quarto dei dati dello yard sorgente e nasconde i DID dei partecipanti, così una modifica rischiosa si prova senza toccare la produzione o le sue persone.
Una migrazione sposta le carte, non le macchine
Una risposta migrate riporta esplicitamente movesDurableObjects: false, così nessuno scambia un cambio di record di sede per un vero spostamento di dati.
Quando usare altro
Hosting Yards autonomo, Hiring Hall o cristallizzazione. import è un 501 fisso finché non è soddisfatto il contratto di import separato; questo modulo avvolge solo ciò che esiste già nel codice.
Spostare Durable Object tra tenant. plan-merge e split-plan sono simulazioni che esplicitamente non uniscono né dividono mai lo storage reale.
Decidere cosa può fare un agente dentro lo yard. Quello è mandates.compile e coordination.admit; uno yard è dove si lavora, non ciò che autorizza.
Prove
Garanzie
Cosa fa e cosa non fa
Un modulo è una promessa forte su una cosa circoscritta. Contaci esattamente per ciò che è.
Fa
Uno yard letto da yards.list esiste con un id, una sede e un pacchetto di regole reali, non una voce pianificata o da modello.
Una modifica al manifest non può applicarsi senza un’approvazione umana legata al digest o una copertura sotto un limite ratificato; la concessione generalizzata */**/all non può mai essere coperta da un limite.
Un fork è uno yard reale, elencato a parte, con i propri sette ruoli, non un riquadro di anteprima in sola lettura.
La prova di continuità di una migrazione è concatenata Merkle alla precedente, quindi un from obsoleto o fuori ordine è rifiutato.
Non fa
Che una migrazione abbia spostato il calcolo reale dello yard. migrate sposta la sede registrata e registra una prova; i Durable Object restano dove li mette rehoming.plan.
Che plan-merge o split-plan abbiano cambiato qualcosa. Entrambi riportano wouldMergeDos/wouldSplitDos come false e non toccano nulla.
Che un fork effimero possa mai diventare ciò da cui è nato. mark-ephemeral rende la promozione permanentemente rifiutata per quel fork.
Dettagli
Note di sviluppo
Prima di costruire
I ruoli si legano a un ruolo, non a un titolare
Un ruolo è indirizzato da role + yardId, mai da DID, quindi riassegnarlo non richiede che nulla di dipendente se ne accorga o cambi.
Apply saltava del tutto il diff
Una versione precedente di apply riceveva un manifest e lo salvava senza diff, piano né verifica di approvazione. Quel buco è chiuso; ogni apply passa ora da plan o da un limite.
Un pacchetto illeggibile fallisce chiuso
Se il pacchetto del manifest corrente non può essere letto, apply rifiuta con 503 invece di trattare l’organizzazione come priva di grant esistenti.
Limiti e misurazione
import risponde sempre 501; l’import Yards autonomo resta bloccato finché il suo documento di contratto non è segnato pronto, indipendentemente dallo stato dello store.
Un limite non può mai coprire una concessione generalizzata su *, ** o all; quella soglia non è riducibile da configurazione.
Via MCP sono esposti solo list e get; create, plan, apply, fork, migrate e teardown sono oggi azioni operatore solo REST.
Accesso
API e MCP
REST e MCP
Autenticati con una chiave API del workspace come token Bearer. L’URL di base è https://api.intramedial.com.
Endpoint REST
GET/api/v1/acp/yards/listElenca gli yard registrati di questo workspace.
GET/api/v1/acp/yards/getLeggi uno yard per id.
Azioni MCP
MCPcoordination.yards.listElenca gli yard come azione MCP.
MCPcoordination.yards.getLeggi uno yard come azione MCP.
Modulo della piattaforma
