Menu
Use when changing PilotSwarm durable orchestration behavior, continue-as-new state, or replay-sensitive control flow.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
The order of operations for changing a live agent safely — diagnose, patch, publish, converge, verify, roll back. Use whenever you are about to modify an agent package that something is already running on.
Deploy PilotSwarm to AKS using the repo's canonical scripts and checks. Use when refreshing secrets, building/pushing the worker image, rolling out to AKS, or verifying provider/model changes in the live cluster.
Reset remote PilotSwarm state for AKS safely. Use when wiping the PilotSwarm database/blob state, clearing stale orchestration history, or recovering from namespace drift and replay/nondeterminism issues.
Use when bringing up a fresh, isolated PilotSwarm environment (`mysandbox`, `myenv2`, etc.) via the npm Bicep/GitOps orchestrator at `deploy/scripts/deploy.mjs`. Covers `new-env` scaffolding, EDGE_MODE × TLS_SOURCE selection, the `all` aggregate, per-service redeploys with `--steps`, force-redeploy semantics, verification, and teardown. Strictly separate from the legacy bash path operated by `scripts/deploy-aks.sh`.
Use after deploying a PilotSwarm stamp with VPN_GATEWAY_ENABLED=true when an operator needs the Azure VPN client profile (azurevpnconfig.xml). Wraps deploy/scripts/auth/Get-VpnClientProfile.ps1 — downloads the gateway-issued profile zip via 'az network vnet-gateway vpn-client generate' and extracts it under the gitignored deploy/envs/local/<env>/vpn-client/ folder. The XML is the same for every user (no per-user credentials), and end users still authenticate with their own Entra ID at connect time.
How to compute model latency and estimated $ cost from PilotSwarm observability data. Read this before reporting that a model is "slow" or "expensive" — most apparent slowness is orchestration overhead, not model inference, and most cost numbers are guesses unless they reference a real published price card.
| name | pilotswarm-duroxide-versioning |
| description | Use when changing PilotSwarm durable orchestration behavior, continue-as-new state, or replay-sensitive control flow. |
PilotSwarm durable orchestrations replay from history. Treat every orchestration change as a wire-compatibility problem, not just a code diff.
packages/sdk/src/orchestration_<version>.ts.continueAsNewVersioned(...) calls.OrchestrationInput payload as a durable wire format. Every new latest version must accept and normalize input snapshots from the oldest orchestration version that is still registered in the codebase.N can continueAsNew from state point X, version N+1 must behave correctly when resumed from X.N+1 only works when resumed from a new point Y, that is a versioning bug unless the older path stays on the old handler.continueAsNew state changes, treat it as a new orchestration version even when the diff is small.continueAsNew upgrades to latest as intended)packages/sdk/test/local/orchestration-version-upgrade.test.js aligned so it still exercises upgrade from the last three frozen versions into the latest version.packages/sdk/test/local/orchestration-version-upgrade.test.js updated for the new latest version and the rolling last-three compatibility matrix