[bmscomp]

Why

kates migrate run, cutover and down take a while, and every kubectl and helm call they make went through defaultRunner, which reads the kube context that is current when that call runs. Say someone runs kubectl config use-context in another terminal partway through. The remaining helm installs of an up, the cutover's upgrade, or down's topic deletes then land on the other cluster. On a laptop that holds both a lab and a real cluster, down --delete-data could delete topics on the wrong one.

What changed

• migrateCmd now has a PersistentPreRunE (cli/cmd/migrate.go). It runs the root's pre-run first, the way connect.go does, because Cobra runs only the nearest one. Then it calls the new pinMigrateKubeContext.
• pinMigrateKubeContext reads kubectl config current-context once through defaultRunner and passes the result to the existing pinKubeContext, the same mechanism deploy uses. After that, every kubectl and helm call the migrate commands make through runProcFn carries --context / --kube-context for that cluster.
• No migrate subcommand switches the context itself. I checked for kind create, use-context, --context and KUBECONFIG in cmd/migrate*.go and pkg/migrate. image build's kind load names its cluster with --name, so pinning at the start is safe.
• If there is no current context (no kubeconfig), nothing is pinned and behaviour is unchanged. Cobra skips pre-run hooks for --help; kates migrate --help still works with KUBECONFIG=/nonexistent.
• The pin is never undone. kates runs one command per process, and nothing runs the migrate command tree in-process (no MCP tool or Execute reuse).

Tests

• New TestMigrateDownStaysOnTheContextItStartedOn (cli/cmd/migrate_down_test.go) runs migrate down --yes --delete-data against the fakeProc. The fake answers kind-panda to the first current-context call and kind-other to every later one. The test asserts that every later kubectl/helm call carries --context=kind-panda or --kube-context=kind-panda, and that migrateCmd.PersistentPreRunE is set.
• cd cli && go vet ./...: clean
• cd cli && go test ./...: pass (includes the TestMCPCaveat* anchors)
• cd cli && golangci-lint run --new-from-rev=$(git merge-base HEAD origin/main) ./...: 0 issues
• gofmt -l on the two edited files: clean
• cd kates && ./mvnw test -Dquarkus.grpc.codegen.skip=true -Dquarkus.http.test-port=0: BUILD SUCCESS, 1747 tests, 0 failures, 3 skipped
• cd kates && ./mvnw -o -q spotless:check (JDK 25): pass

Only CI can run these: the integration tests, the native image, the Kind and Docker jobs, and CodeQL.

Deliberately not done

• No docs, SKILL.md or MCP caveat describes how migrate picks its context, so none needed changing.
• No kates/ Java changed, so no caveat line refs moved.
• No --context flag for migrate. Nobody asked for one; pinning the context the command started on is the fix.