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…
rehoming.planModulo 52
Modulo della piattaforma
Region rehoming
Pianifica dove devono vivere i record di coordinamento di questo workspace, vedi esattamente cosa si sposterebbe, poi portalo in un’altra regione quando decidi tu.
rehoming.plan indica una regione di origine e una di destinazione per stato, lease e righe del ledger del workspace. execute copia uno snapshot reale che la regione di destinazione preleva da sé; la presenza live resta regionale, e un workspace legato all’UE è fissato rifiutando le chiamate dalla vecchia regione una volta registrato.
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.
RehomingSnapshot.signed è sempre false; non esiste un’attestazione crittografica del trasferimento. plan ed execute salvano nello store di policy e in una chiave di configurazione, ma nessuno chiama appendEvent del ledger, quindi “registrato” significa scritto lì, non nel ledger di audit usato dagli altri moduli.
Registro
Il registro
Cosa viene registrato
from
La regione attuale del workspace.
to
La regione di destinazione richiesta.
pinDOs
Se le classi Durable Object sono fissate alla destinazione come parte di questo spostamento.
Se la regione di destinazione è una giurisdizione UE, che determina il pin 421 dopo l’esecuzione.
status
planned da plan, o lo stato registrato da status.
workflowId
Impostato quando execute gira come Cloudflare Workflow asincrono anziché inline.
Meccanismo
Passo dopo passo
Come funziona
Uno spostamento è pianificato
plan con una regione to di destinazione restituisce from calcolato, le classi Durable Object fissate e se la destinazione è legata all’UE, come oggetto piatto, non racchiuso in una chiave plan.
L’esecuzione cattura uno snapshot reale
execute legge le chiavi attive dello store di policy, i lease, le righe D1 e lo stato dei Durable Object, comprese le foglie del ledger non sigillate, e lo scrive in una chiave sidecar CONFIG_KV condivisa per il workspace.
La destinazione preleva, non riceve mai un push
La regione di destinazione applica lo snapshot in modo lazy alla propria prossima richiesta per questo workspace, con chiave idempotente data dal timestamp dello snapshot stesso.
Un pin UE ha effetto una volta registrato
Una volta registrato uno spostamento legato all’UE, ogni altra chiamata a un modulo ACP dalla vecchia regione restituisce 421 per questo workspace, tranne le route proprie di rehoming, che restano raggiungibili ovunque per ispezione.
Provalo
Demo live
Eseguilo da questa pagina
GET/api/v1/acp/rehoming/status
// 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 rehoming.plan
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.
api.intramedial.com/api/v1/acp/rehoming/planPOST
POST/api/v1/acp/rehoming/planAuthorization: Bearer av_workspace_••••Content-Type: application/json
{
"to": "weur"
}
→ 200 { from, to, pinDOs, doClasses, targetWorker, euBound, status, workflowId, llm } (flat; the { plan } wrapper is what rehoming.status returns, not rehoming.plan)
Un workspace pianifica uno spostamento in weur, lo esegue, e da allora ogni chiamata dalla vecchia regione è rifiutata con 421 invece di servire in silenzio dati obsoleti.
Eseguire la cattura inline
Passare forceInline: true esegue la cattura e la persistenza dello snapshot in modo sincrono invece di affidarle a un Workflow, utile quando un workspace piccolo non ha bisogno del percorso asincrono.
Tenere le sessioni live dove sono
Un workspace che cambia regione mantiene i websocket PresenceHub attivi collegati alla regione di origine; nello snapshot viaggiano solo le ultime righe di presenza note, non le connessioni aperte.
Rieseguire status da qualsiasi regione
Un operatore controlla status dalla regione in cui sta lavorando, perché le route proprie di rehoming restano raggiungibili anche dopo l’entrata in vigore di un pin UE.
Quando usare altro
Uno spostamento atomico e distruttivo. L’esecuzione copia uno snapshot e lascia che la destinazione lo prelevi; in quel momento nulla è cancellato dall’origine.
Un trasferimento attestato crittograficamente. Il campo signed dello snapshot è sempre false; non c’è firma su ciò che si è spostato.
Un registro nel ledger di audit dello spostamento. Plan ed execute scrivono nello store di policy e in una chiave di configurazione, mai nel ledger di coordinamento che legge ledger.blame.
Prove
Garanzie
Cosa fa e cosa non fa
Un modulo è una promessa forte su una cosa circoscritta. Contaci esattamente per ciò che è.
Fa
Un workspace legato all’UE, una volta registrato il suo spostamento, rifiuta con 421 ogni chiamata ACP non di rehoming da qualsiasi altra regione di produzione.
Uno snapshot catturato include chiavi attive dello store di policy, lease, righe D1 e stato dei Durable Object, non solo un’etichetta di regione.
Le connessioni PresenceHub live non sono mai migrate; solo le loro ultime righe note sono copiate nello snapshot.
Non fa
Che il trasferimento sia firmato crittograficamente. signed è sempre false sullo snapshot che il modulo scrive.
Che lo spostamento sia scritto nel ledger usato dagli altri moduli. È registrato nello store di policy e in una chiave di configurazione, non tramite appendEvent.
Che execute richieda a sua volta una conferma umana. A differenza del percorso di ripristino di remediation.blast, rehoming non ha un passo di conferma separato prima dell’esecuzione.
Dettagli
Note di sviluppo
Prima di costruire
La forma di plan è piatta
La risposta dell’azione plan non è racchiusa in una chiave plan; quel wrapper compare solo dall’azione separata status, che restituisce { plan: stored }.
Si spostano ventidue percorsi di policy
Una cattura percorre un elenco fisso di percorsi dello store di policy insieme a lease, righe D1 e stato dei Durable Object; nulla fuori da quell’elenco è catturato.
La modalità dev è esente dal pin
Il pin UE 421 si applica solo quando ITML_REGION è una regione di produzione attiva; la regione di sviluppo locale è esente così un workspace può ancora essere lavorato in locale dopo uno spostamento pianificato.
Limiti e misurazione
execute scrive uno snapshot non firmato; non c’è alcuna attestazione del trasferimento da verificare in seguito.
Lo spostamento non è scritto nel ledger di coordinamento; ledger.blame non lo mostrerà.
Non esiste un’azione restore; il ciclo di vita è esattamente plan, execute e status.
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
POST/api/v1/acp/rehoming/planPianifica uno spostamento di regione e vedi cosa copre.
POST/api/v1/acp/rehoming/executeCattura e salva lo snapshot che la regione di destinazione deve prelevare.
GET/api/v1/acp/rehoming/statusLeggi il piano registrato e il suo stato.
Azioni MCP
MCPcoordination.rehoming.planPianifica uno spostamento come azione MCP.
MCPcoordination.rehoming.executeEsegui uno spostamento pianificato come azione MCP.
MCPcoordination.rehoming.statusLeggi lo stato del rehoming come azione MCP.
Modulo della piattaforma
