O Intramedial está em beta restrito. Ao se cadastrar ou entrar, você precisa informar a senha de beta tester que recebeu ou solicitar uma em preview@intramedial.com. Obrigado.
Carregando…
rehoming.planMódulo 52
Módulo da plataforma
Region rehoming
Planeje onde os registros de coordenação deste workspace devem ficar, veja exatamente o que seria movido e depois leve-os a outra região quando você decidir.
rehoming.plan nomeia uma região de origem e uma de destino para o estado, os leases e as linhas do ledger do workspace. execute copia um snapshot real que a região de destino puxa por conta própria; a presença ativa permanece regional, e um workspace ligado à UE é fixado recusando chamadas da região antiga depois de registrado.
Os agentes agem quando o plano diz sim, e o registo diz porquê.
Passe ações de agentes, hashes de conteúdo, checagens de API, DNS, webhooks, chamadas de LLM e commits git pela Intramedial. Receba um recibo assinado que todos verificam – sem confiar em nós.
RehomingSnapshot.signed é sempre false; não há atestação criptográfica da transferência. plan e execute persistem no armazenamento de políticas e em uma chave de configuração, mas nenhum chama appendEvent do ledger, então "registrado" significa gravado ali, não no ledger de auditoria que outros módulos usam.
Registro
O registro
O que é registrado
from
A região atual do workspace.
to
A região de destino solicitada.
pinDOs
Se as classes de Durable Object são fixadas no destino como parte desta mudança.
Se a região de destino é uma jurisdição da UE, o que aciona a fixação 421 após a execução.
status
planned de plan, ou o estado registrado de status.
workflowId
Definido quando execute roda como um Cloudflare Workflow assíncrono em vez de na hora.
Mecanismo
Passo a passo
Como funciona
Uma mudança é planejada
plan com uma região de destino to devolve o from calculado, as classes de Durable Object fixadas e se o destino é ligado à UE, como um objeto plano, não envolvido em uma chave plan.
A execução captura um snapshot real
execute lê chaves ativas do armazenamento de políticas, leases, linhas D1 e estado de Durable Objects, inclusive folhas de ledger sem selo, e o grava em uma chave sidecar compartilhada CONFIG_KV para o workspace.
O destino puxa, nunca é empurrado
A região de destino aplica o snapshot de forma preguiçosa na própria próxima requisição a este workspace, com idempotência dada pelo carimbo de tempo do próprio snapshot.
Uma fixação na UE vale depois de registrada
Depois que uma mudança ligada à UE é registrada, toda outra chamada de módulo ACP da região antiga retorna 421 para este workspace, exceto as rotas do próprio rehoming, que continuam acessíveis em qualquer lugar para inspeção.
Experimente
Demo ao vivo
Execute a partir desta página
GET/api/v1/acp/rehoming/status
// Sem corpo: isto é um GET. Clique em Executar.
Executa em um workspace de demonstração compartilhado com uma chave de demonstração: qualquer pessoa pode ver o que ele contém, então não envie nada privado. Docs de rehoming.plan
Respostas
Clique em Executar para enviar a requisição à esquerda ao workspace de demonstração compartilhado.
Executa em um workspace de demonstração compartilhado com uma chave de demonstração: qualquer pessoa pode ver o que ele contém, então não envie nada privado.
Código
Exemplo ao vivo
Uma requisição real
Uma requisição no formato que a API aceita e um exemplo de resposta no formato que o módulo devolve.
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)
Um workspace planeja uma mudança para weur, a executa, e a partir daí toda chamada de sua região antiga é recusada com 421 em vez de servir dados desatualizados em silêncio.
Executar a captura na hora
Passar forceInline: true executa a captura e a persistência do snapshot de forma síncrona em vez de entregá-las a um Workflow, útil quando um workspace pequeno não precisa do caminho assíncrono.
Manter as sessões ativas onde estão
Um workspace que muda de região mantém seus websockets PresenceHub ativos conectados à região de origem; só as últimas linhas de presença conhecidas viajam no snapshot, não as próprias conexões abertas.
Reexecutar status de qualquer região
Um operador confere status da região em que estiver trabalhando, pois as rotas do próprio rehoming continuam acessíveis mesmo depois que uma fixação na UE entra em vigor.
Quando usar outra coisa
Uma mudança atômica e destrutiva. A execução copia um snapshot e deixa o destino puxá-lo; nada é apagado da origem nesse momento.
Uma transferência atestada criptograficamente. O campo signed do snapshot é sempre false; não há assinatura sobre o que foi movido.
Um registro da mudança no ledger de auditoria. Plan e execute gravam no armazenamento de políticas e em uma chave de configuração, nunca no ledger de coordenação que ledger.blame lê.
Evidência
Garantias
O que faz e o que não faz
Um módulo é uma afirmação forte sobre algo estreito. Confie nele exatamente pelo que ele é.
Faz
Um workspace ligado à UE, depois de registrada a mudança, recusa com 421 toda chamada ACP que não seja de rehoming vinda de qualquer outra região de produção.
Um snapshot capturado inclui chaves ativas do armazenamento de políticas, leases, linhas D1 e estado de Durable Objects, não apenas um rótulo de região.
As conexões PresenceHub ativas nunca são migradas; só suas últimas linhas conhecidas são copiadas para o snapshot.
Não faz
Que a transferência seja assinada criptograficamente. signed é sempre false no snapshot que o módulo grava.
Que a mudança seja gravada no ledger que outros módulos usam. Ela é registrada no armazenamento de políticas e em uma chave de configuração, não por appendEvent.
Que execute dependa de uma confirmação humana. Diferente do caminho de restauração de remediation.blast, o rehoming não tem etapa de confirmação separada antes da execução.
Detalhes
Notas de construção
Antes de construir
O formato de plan é plano
A resposta da ação plan não é envolvida em uma chave plan; esse envoltório só aparece na ação status separada, que devolve { plan: stored }.
Vinte e dois caminhos de política se movem
Uma captura percorre uma lista fixa de caminhos do armazenamento de políticas junto com leases, linhas D1 e estado de Durable Objects; nada fora dessa lista é capturado.
O modo dev é isento da fixação
A fixação 421 da UE só se aplica quando ITML_REGION é uma região de produção ativa; a região de desenvolvimento local é isenta para que um workspace ainda possa ser trabalhado localmente após uma mudança planejada.
Limites e medição
execute grava um snapshot sem assinatura; não há atestação da transferência para verificar depois.
A mudança não é gravada no ledger de coordenação; ledger.blame não a mostrará.
Não existe ação restore; o ciclo de vida é exatamente plan, execute e status.
Acesso
API e MCP
REST e MCP
Autentique-se com uma chave de API do workspace como token Bearer. A URL base é https://api.intramedial.com.
Endpoints REST
POST/api/v1/acp/rehoming/planPlaneje uma mudança de região e veja o que ela cobre.
POST/api/v1/acp/rehoming/executeCapture e persista o snapshot para a região de destino puxar.
GET/api/v1/acp/rehoming/statusLeia o plano registrado e seu status.
Ações MCP
MCPcoordination.rehoming.planPlaneje uma mudança como ação MCP.
MCPcoordination.rehoming.executeExecute uma mudança planejada como ação MCP.
MCPcoordination.rehoming.statusLeia o status do rehoming como ação MCP.
Inspecione o que um agente lembra e tire um snapshot assinado, com raiz Merkle, da sua memória, com um armazenamento versionado e restrito ao workspace.