Intramedial befindet sich in der eingeschränkten Beta. Bei der Registrierung oder Anmeldung müssen Sie das erhaltene Beta-Tester-Passwort angeben oder unter preview@intramedial.com eines anfordern. Vielen Dank.
Wird geladen…
rehoming.planModul 52
Plane-Modul
Region rehoming
Planen Sie, wo die Koordinationsdaten dieses Workspace liegen sollen, sehen Sie genau, was umzöge, und tragen Sie es dann auf Ihr eigenes Kommando in eine andere Region.
rehoming.plan nennt eine Quell- und Zielregion für Zustand, Leases und Ledger-Zeilen des Workspace. execute kopiert einen echten Snapshot, den die Zielregion selbst abruft; Live-Presence bleibt regional, und ein EU-gebundener Workspace wird festgesetzt, indem Aufrufe aus der alten Region nach der Erfassung abgelehnt werden.
Agenten handeln, wenn die Ebene Ja sagt – und das Protokoll sagt, warum.
Leiten Sie Agent-Aktionen, Inhalts-Hashes, API-Checks, DNS-Abfragen, Webhooks, LLM-Aufrufe und Git-Commits über Intramedial – für einen signierten Beleg, den jeder prüft, ohne uns zu vertrauen.
RehomingSnapshot.signed ist immer false; es gibt keine kryptografische Attestierung der Übertragung. plan und execute schreiben in den Policy-Store und einen Config-Schlüssel, aber keines ruft appendEvent des Ledgers auf, sodass „erfasst“ dort Geschriebenes meint, nicht das Audit-Ledger, das andere Module nutzen.
Protokoll
Das Protokoll
Was erfasst wird
from
Die aktuelle Region des Workspace.
to
Die gewünschte Zielregion.
pinDOs
Ob Durable-Object-Klassen im Rahmen dieses Umzugs am Ziel festgesetzt werden.
Ob die Zielregion eine EU-Jurisdiktion ist, was die 421-Festsetzung nach der Ausführung steuert.
status
planned von plan, oder der erfasste Zustand von status.
workflowId
Gesetzt, wenn execute als asynchroner Cloudflare Workflow statt inline läuft.
Mechanismus
Schritt für Schritt
So funktioniert es
Ein Umzug wird geplant
plan mit einer Zielregion to liefert die berechnete from, die festgesetzten Durable-Object-Klassen und ob das Ziel EU-gebunden ist, als flaches Objekt, nicht in einen plan-Schlüssel gepackt.
Die Ausführung erfasst einen echten Snapshot
execute liest Live-Policy-Store-Schlüssel, Leases, D1-Zeilen und Durable-Object-Zustand, einschließlich unversiegelter Ledger-Blätter, und schreibt sie in einen gemeinsamen CONFIG_KV-Sidecar-Schlüssel für den Workspace.
Das Ziel zieht, es wird nie gepusht
Die Zielregion wendet den Snapshot träge bei ihrer nächsten eigenen Anfrage an diesen Workspace an, idempotent über den eigenen Zeitstempel des Snapshots geschlüsselt.
Eine EU-Festsetzung greift, sobald sie erfasst ist
Sobald ein EU-gebundener Umzug erfasst ist, gibt jeder andere ACP-Modulaufruf aus der alten Region für diesen Workspace 421 zurück, außer den eigenen Rehoming-Routen, die zur Inspektion überall erreichbar bleiben.
Ausprobieren
Live-Demo
Direkt auf dieser Seite ausführen
GET/api/v1/acp/rehoming/status
// Kein Body: Das ist ein GET. Klicken Sie auf Ausführen.
Läuft in einem gemeinsamen Demo-Workspace mit einem Demo-Schlüssel: Jeder kann sehen, was darin liegt, senden Sie also nichts Privates. Doku zu rehoming.plan
Antworten
Klicken Sie auf Ausführen, um die Anfrage links an den gemeinsamen Demo-Workspace zu senden.
Läuft in einem gemeinsamen Demo-Workspace mit einem Demo-Schlüssel: Jeder kann sehen, was darin liegt, senden Sie also nichts Privates.
Code
Live-Beispiel
Eine echte Anfrage
Eine Anfrage in der Form, die die API akzeptiert, und eine Beispielantwort in der Form, die das Modul liefert.
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)
Ein Workspace plant einen Umzug nach weur, führt ihn aus, und von da an wird jeder Aufruf aus seiner alten Region mit 421 abgelehnt, statt stillschweigend veraltete Daten zu liefern.
Die Erfassung inline ausführen
Mit forceInline: true laufen Snapshot-Erfassung und Persistierung synchron statt über einen Workflow, nützlich, wenn ein kleiner Workspace den asynchronen Pfad nicht braucht.
Live-Sitzungen dort lassen, wo sie sind
Ein Workspace beim Regionswechsel behält seine Live-PresenceHub-Websockets mit der Quellregion verbunden; nur die zuletzt bekannten Presence-Zeilen reisen im Snapshot mit, nicht die offenen Verbindungen selbst.
Den Status aus jeder Region erneut abfragen
Ein Betreiber prüft status aus der Region, in der er gerade arbeitet, da die eigenen Routen des Rehoming auch nach Wirksamwerden einer EU-Festsetzung erreichbar bleiben.
Wann etwas anderes passt
Ein atomarer, destruktiver Umzug. Die Ausführung kopiert einen Snapshot und lässt das Ziel ihn abrufen; in diesem Moment wird nichts aus der Quelle gelöscht.
Eine kryptografisch attestierte Übertragung. Das Feld signed des Snapshots ist immer false; es gibt keine Signatur über das Verschobene.
Ein im Audit-Ledger erfasster Eintrag des Umzugs. Plan und Execute schreiben in den Policy-Store und einen Config-Schlüssel, nie in das Koordinations-Ledger, das ledger.blame liest.
Nachweis
Garantien
Was es leistet und was nicht
Ein Modul ist eine starke Aussage über etwas Enges. Verlassen Sie sich genau darauf.
Es leistet
Ein EU-gebundener Workspace lehnt, sobald sein Umzug erfasst ist, jeden Nicht-Rehoming-ACP-Aufruf aus jeder anderen Produktivregion mit 421 ab.
Ein erfasster Snapshot enthält Live-Policy-Store-Schlüssel, Leases, D1-Zeilen und Durable-Object-Zustand, nicht nur ein Regionslabel.
Live-PresenceHub-Verbindungen werden nie migriert; nur ihre zuletzt bekannten Zeilen werden in den Snapshot kopiert.
Es leistet nicht
Dass die Übertragung kryptografisch signiert ist. signed ist im vom Modul geschriebenen Snapshot immer false.
Dass der Umzug in das Ledger geschrieben wird, das andere Module nutzen. Er wird im Policy-Store und einem Config-Schlüssel erfasst, nicht über appendEvent.
Dass execute selbst an eine menschliche Bestätigung gebunden ist. Anders als der Restore-Pfad von remediation.blast hat Rehoming vor der Ausführung keinen separaten Bestätigungsschritt.
Details
Bauhinweise
Bevor Sie bauen
Die Form von plan ist flach
Die Antwort der Aktion plan ist nicht in einen plan-Schlüssel gepackt; dieser Wrapper erscheint nur bei der separaten Aktion status, die { plan: stored } liefert.
Zweiundzwanzig Policy-Pfade ziehen um
Eine Erfassung durchläuft eine feste Liste von Policy-Store-Pfaden neben Leases, D1-Zeilen und Durable-Object-Zustand; nichts außerhalb dieser Liste wird erfasst.
Der Dev-Modus ist von der Festsetzung ausgenommen
Die EU-421-Festsetzung greift nur, wenn ITML_REGION eine Live-Produktivregion ist; die lokale Entwicklungsregion ist ausgenommen, damit ein Workspace nach einem geplanten Umzug lokal weiter bearbeitet werden kann.
Limits und Bemessung
execute schreibt einen unsignierten Snapshot; es gibt keine Attestierung der Übertragung, die sich später prüfen ließe.
Der Umzug wird nicht in das Koordinations-Ledger geschrieben; ledger.blame zeigt ihn nicht.
Es gibt keine Aktion restore; der Lebenszyklus besteht genau aus plan, execute und status.
Zugriff
API & MCP
REST und MCP
Authentifizieren Sie sich mit einem Workspace-API-Schlüssel als Bearer-Token. Die Basis-URL ist https://api.intramedial.com.
REST-Endpunkte
POST/api/v1/acp/rehoming/planEinen Regionsumzug planen und sehen, was er abdeckt.
POST/api/v1/acp/rehoming/executeDen Snapshot erfassen und für die Zielregion zum Abruf ablegen.
GET/api/v1/acp/rehoming/statusDen erfassten Plan und seinen Status lesen.
MCP-Aktionen
MCPcoordination.rehoming.planEinen Umzug als MCP-Aktion planen.
MCPcoordination.rehoming.executeEinen geplanten Umzug als MCP-Aktion ausführen.
MCPcoordination.rehoming.statusDen Rehoming-Status als MCP-Aktion lesen.
Prüfen Sie, was ein Agent sich merkt, und erstellen Sie einen signierten, Merkle-verankerten Snapshot seines Gedächtnisses, mit einem versionierten, workspace-bezogenen Store.
Plane-Modul
