Intramedial est en bêta restreinte. À l’inscription ou à la connexion, vous devez fournir le mot de passe de bêta-testeur que vous avez reçu ou en demander un à preview@intramedial.com. Merci.
Chargement…
yards.listModule 44
Module du plan
Registered yards
Voyez tous les yards persistants et gouvernés enregistrés dans cet espace de travail, chacun avec sa propre constitution et les postes qui l'occupent.
yards.list lit les yards dans lesquels votre flotte tourne réellement, construits et exécutés dans Yards, la plateforme autonome qui leur est dédiée. Chaque yard reçoit son id, un lieu, un pack de règles et sept postes standard dès sa création, et d'autres routes permettent de le forker, migrer, amender ou démonter.
Les agents agissent quand le plan dit oui, et le registre dit pourquoi.
Faites passer actions d’agents, hash de contenu, contrôles d’API, requêtes DNS, webhooks, appels LLM et commits git par Intramedial. Obtenez un reçu signé vérifiable par tous – sans nous croire.
local, cloud, wnam, weur, apac ou oc ; un lieu inconnu est refusé plutôt qu'accepté comme texte libre.
open
Indique si le yard est toujours en cours d'exécution.
participantDids
Les agents mis en place dans le yard.
migrations
L'historique des changements de lieu du yard, chaque étape chaînée à la précédente.
fork
Présent quand le yard est lui-même un fork, avec son yard source et ses masquages.
Mécanisme
Pas à pas
Comment ça marche
Un yard est enregistré
create enregistre un yard avec un title, un packId et un venue, et met en place la flotte nommée dans participantDids.
Sept postes sont pourvus automatiquement
La création appelle la routine de dotation de roles.charters, qui pourvoit yardmaster, steward, librarian, gatekeeper, clerk, auditor et treasurer du nouveau yard avant toute autre chose.
Les changements passent d'abord par un diff
plan prévisualise un changement de manifeste sous forme de diff avec un condensat ; apply ne prend effet qu'avec une approbation humaine correspondante ou une couverture par une borne ratifiée, jamais sur le seul manifeste.
Un fork échantillonne, ne copie jamais tout
fork construit un vrai yard à partir d'un échantillon des données de la source, avec des champs nommés masqués, et peut être marqué éphémère pour ne jamais pouvoir être promu en retour.
La migration déplace le lieu, pas le calcul
migrate enregistre une preuve de continuité chaînée en Merkle pour un changement de lieu. Elle ne déplace explicitement pas les Durable Objects ; cela relève de rehoming.plan, à l'échelle du plan.
Essayer
Démo en direct
Exécutez-le depuis cette page
GET/api/v1/acp/yards/list
// Pas de corps : c’est un GET. Appuyez sur Exécuter.
S’exécute dans un workspace de démonstration partagé avec une clé de démonstration : tout le monde peut voir ce qu’il contient, n’envoyez donc rien de privé. Docs yards.list
Réponses
Appuyez sur Exécuter pour envoyer la requête de gauche au workspace de démonstration partagé.
S’exécute dans un workspace de démonstration partagé avec une clé de démonstration : tout le monde peut voir ce qu’il contient, n’envoyez donc rien de privé.
Code
Exemple en direct
Une vraie requête
Une requête dans la forme acceptée par l’API, et un exemple de réponse dans la forme renvoyée par le module.
Un opérateur lit yards.list pour voir chaque yard dans lequel une flotte tourne réellement aujourd'hui, pas un plan de ce qui devrait exister.
Prévisualiser un changement de politique avant qu'il s'applique
plan montre le diff exact qu'un changement de manifeste produirait, avec un condensat, avant que quiconque l'approuve ou qu'une borne le laisse passer.
Essayer d'abord un changement sur une copie échantillonnée
Un fork échantillonne par défaut un quart des données du yard source et masque les DID des participants, donc un changement risqué peut être essayé sans toucher la production ni ses personnes.
Une migration déplace des papiers, pas des machines
Une réponse migrate indique explicitement movesDurableObjects: false, pour que personne ne confonde un changement d'enregistrement de lieu avec un vrai déplacement de données.
Quand utiliser autre chose
L'hébergement Yards autonome, Hiring Hall ou la cristallisation. import renvoie un 501 ferme tant que le contrat d'import distinct n'est pas satisfait ; ce module n'enveloppe que ce qui existe déjà dans l'arbre.
Déplacer des Durable Objects entre tenants. plan-merge et split-plan sont des simulations qui ne fusionnent ni ne scindent jamais le stockage réel.
Décider de ce qu'un agent dans le yard peut faire. Cela relève de mandates.compile et coordination.admit ; un yard est l'endroit où le travail se fait, pas ce qui l'autorise.
Preuves
Garanties
Ce qu’il fait, et ce qu’il ne fait pas
Un module est une affirmation forte sur un sujet étroit. Fiez-vous-y exactement pour ce qu’il est.
Il le fait
Un yard lu depuis yards.list existe, avec un vrai id, un lieu et un pack de règles, et n'est pas une entrée prévue ou modélisée.
Un changement de manifeste ne peut pas s'appliquer sans une approbation humaine liée au condensat ou une couverture par une borne ratifiée ; l'habilitation générale */**/all ne peut jamais être couverte par une borne.
Un fork est un vrai yard listé séparément, avec ses propres sept postes, pas un volet d'aperçu en lecture seule.
La preuve de continuité d'une migration est chaînée en Merkle à la précédente, donc un from périmé ou hors séquence est refusé.
Il ne le fait pas
Qu'une migration a déplacé le calcul réel du yard. migrate déplace le lieu enregistré et enregistre une preuve ; les Durable Objects restent là où rehoming.plan les place.
Que plan-merge ou split-plan a changé quoi que ce soit. Les deux rapportent wouldMergeDos/wouldSplitDos à false et ne touchent à rien.
Qu'un fork éphémère peut jamais redevenir ce dont il a été forké. mark-ephemeral rend la promotion définitivement refusée pour ce fork.
Détails
Notes de conception
Avant de construire
Les postes se lient à un rôle, pas à un titulaire
Un poste est adressé par role + yardId, jamais par DID, donc le re-pourvoir n'oblige rien de ce qui en dépend à le remarquer ni à changer.
Apply sautait entièrement le diff
Une version antérieure d'apply prenait un manifeste et le persistait sans diff, sans plan ni vérification d'approbation. Cette faille est fermée ; chaque apply passe désormais par plan ou une borne.
Un pack illisible échoue en fermé
Si le pack du manifeste actuel est illisible, apply refuse avec 503 plutôt que de traiter l'organisation comme n'ayant aucune habilitation existante.
Limites et mesure
import répond toujours 501 ; l'import Yards autonome reste verrouillé jusqu'à ce que son propre document de contrat soit marqué prêt, quel que soit l'état du stockage.
Une borne ne peut jamais couvrir une habilitation générale sur *, ** ou all ; ce plancher ne peut pas être abaissé par configuration.
Seuls list et get sont exposés via MCP ; create, plan, apply, fork, migrate et teardown sont aujourd'hui des actions d'opérateur REST uniquement.
Accès
API et MCP
REST et MCP
Authentifiez-vous avec une clé d’API d’espace de travail comme jeton Bearer. L’URL de base est https://api.intramedial.com.
Points d’accès REST
GET/api/v1/acp/yards/listLister les yards enregistrés de cet espace de travail.
GET/api/v1/acp/yards/getLire un yard par id.
Actions MCP
MCPcoordination.yards.listLister les yards comme action MCP.
MCPcoordination.yards.getLire un yard comme action MCP.
Module du plan
