[antoinetoussaint-byte]

Closes #79.

Moves the vault agent from core v0.17.0 to v0.19.4, from the released tag. No replace, and no codefly pseudo-versions.

The issue says main is on core v0.5.1 with go 1.27.0. Main (5922114) is actually on core v0.17.0 with go 1.27.2, so the jump is two minor versions, not fourteen.

Changes

1. go.mod/go.sum: core v0.17.0 → v0.19.4. Fix. MVS also raises google.golang.org/grpc v1.83.2 → v1.84.0 (a direct require, because core v0.19.4 needs it), otel 1.46 → 1.47 (adds otel/log), go-openapi/swag → v0.29.2, x/sys, genproto, x/exp and docker/go-connections. Nothing is hand-pinned.

2. recovery_scope_test.go: defer func() { _ = os.RemoveAll(dir) }(). Lint-only, so it's neither a fix nor a hack. golangci-lint's errcheck flagged it on main as well. The discard follows the suite's own _ = exec.Command(...).Run() cleanup idiom, and the cleanup itself is unchanged.

3. ci.yml and releaser.yml: core's reusable workflows pinned @main → @v0.19.4. Fix, from review finding F2. Before this, CI and the release changed silently whenever core main changed. At v0.19.4 both files exist at the same paths and are byte-identical to core main today. Each takes only the optional setup-run input, which neither caller passes, and secrets: inherit still supplies the release's GH_PAT.

There are no hacks. Nothing is shimmed, fenced or suppressed.

Call sites adapted

None were needed. The agent builds and vets unchanged. I diffed every core package the agent imports between the two tags. Most are byte-identical. The ones that changed are listed here, with what they mean for this agent:

• agents. The per-spawn auth interceptors moved into core/callertoken, which is now shared with the manager and gateways. I read the new code. It has the same metadata key (x-codefly-token), the same constant-time compare and the same health-only exemption (Health/Check, Health/Watch). An empty expected token still fails closed with Unauthenticated. The one difference is that an empty presented token is now refused explicitly, which is stricter. This agent's auth posture is unchanged or tighter.
• agents/services (base_builder, pod_overlay). Image SBOMs go through sbom.ImageForSubject, which folds in the pin and digest checks the builder used to do inline. Service-account projection was refactored onto a filesystem abstraction and now also refuses remote kustomize references. These are core-internal, and the deployment tests below exercise them unchanged.
• resources. Workspaces now record their declaration path and sha256 on load. That's additive, and this agent doesn't read it.

Constraints from the issue

• go mod graph | grep structured-merge-diff/v7 prints nothing.
• go.mod lists kustomize api/kyaml v0.21.1 and kube-openapi d427ff9ee9ad, not v0.21.3 or 97fa35140926. No downgrade was needed, so none was run.
• Go directive. Core v0.19.4 declares go 1.27.0, below this module's go 1.27.2, so the directive does not move. There is no toolchain line. Both CI workflows use go-version-file: go.mod, so there's nothing to edit there. The golang:1.26.9 images and the grpc v1.83.2 pin in Dockerfile.runtime build upstream HashiCorp Vault against Vault's own go.mod, not this agent's, so they don't follow this bump.
• Legacy. No code, config or doc here is labelled legacy, so there was nothing to delete.
• Docs. No doc in this repo states the core or Go pins (README templates and LOCAL-PERSISTENCE.md were checked), so none changed.
• Security posture. No agent source changed. Dev mode, the fail-closed token paths and the durable/transit provisioning scripts are untouched. TestEphemeralDeploymentFailsClosedWithoutVaultToken, TestVaultServerArgsKeepRootTokenSecret and the provisioning-refusal tests pass on the branch.

Reused

• Core v0.19.4's callertoken interceptors, which the agent picks up through agents.Serve.
• The repo's existing test suite as the behaviour oracle. I didn't add or change any test except the lint line above.
• Core's shared go-service-ci.yml gate list, which I replicated locally.

Verification (local, darwin/arm64, go1.27.2, Docker 29.4.0, nix)

• The go-service-ci.yml gates go build ./..., go vet ./... and go mod tidy -diff are clean.

• golangci-lint run ./... (v2.14.0, default config): 0 issues.

• Before/after proof. I ran VAULT_REQUIRE_NIX=1 go test -race -v ./... -count=1 (the nix-lifecycle job) on this branch and on a worktree of main (5922114). Both runs produced the same 46 passing tests, and both had the same single failure, TestDurableVaultSurvivesRestart, failing the same way (vault provisioning: cannot install VAULT_ACCESS_TOKEN as a vault token). Run on its own on this branch, that test passes (34.9s). Main's CI passed it on 5922114. So it's a load-sensitive flake in the in-container provisioning on this host, present before this change and not caused by it.

• go test -v ./... (the test job as CI runs it): ok, 47 passing, including TestDurableVaultSurvivesRestart, with nothing skipped or failing.

• CI on linux/amd64 passed on ca45904 (run 38407056183) and on 2e03a7d with the pinned workflows: build, test and nix-lifecycle (run 38409271358). That run exercises go-service-ci.yml@v0.19.4. go-service-release.yml@v0.19.4 only runs on a tag, so it was checked by diff rather than run.

Not verified

• No real Kubernetes deploy, release build or published runtime image. releaser.yml and runtime-image.yml were not exercised, and Dockerfile.runtime was not rebuilt (it's untouched).
• I didn't find the cause of the TestDurableVaultSurvivesRestart flake under load on Docker Desktop/arm64. My guess is that auth/token/create-orphan runs before the transit-sealed server is fully active, because its error output is discarded at provision/provision.sh:178, but I haven't confirmed that. I'd file a separate issue for it rather than change the provisioner in this PR.

Release

Not done here. Per agent.codefly.yaml (release.owner: workflow, releaser.yml), the coordinator bumps version 0.0.42 → 0.0.43 in a release: PR as #78 did, then tags. The version is deliberately unchanged in this PR.

Open PR #66 (security-posture audit) edits many of the same source files but neither go.mod nor recovery_scope_test.go, so the two shouldn't conflict textually.

🤖 Generated with Claude Code