[antoinetoussaint-byte]

Closes #75.

Moves the generic agent from core v0.5.1 to core v0.19.4. The change is go.mod and go.sum only. No source file, workflow, image pin or doc changes, and the agent's responses are byte-identical to main's.

Changes

Change	Kind	Why
github.com/codefly-dev/core v0.5.1 → v0.19.4	fix	The point of the issue. Released tag.
google.golang.org/grpc v1.83.2 → v1.84.0 (direct)	fix	Forced by MVS: core v0.19.4 requires it.
Indirect refreshes in go.mod and go.sum (otel 1.47, x/net, x/sys, genproto, go-git, go-openapi/swag …)	fix	Produced by go mod tidy against the new core. Nothing was chosen by hand.

There are no hacks: no replace, no pseudo-version for any codefly module, no //nolint, no shim.

Why no call site needed adapting

The gap from v0.5.1 to v0.19.4 is large, but this agent's surface didn't move:

• The Agent, Runtime, Code and Tooling gRPC service interfaces have exactly the same methods at both pins. I diffed the generated *_grpc.pb.go method sets.
• Every core helper this agent calls compiles unchanged at v0.19.4: services.NewServiceBase, services.Advertisement, services.RuntimeLoad, corecode.NewDefaultCodeServer, WithCachedFS, WithSemanticAnalyzer, NewSourceTooling, lang.NewEditToolboxFromTooling, agents.PluginRegistration, agents.Serve, resources.LoadServiceFromDir, failures.Ensure and failures.Clone.

Pins the go directive drags

None move. Core v0.19.4 declares go 1.27.0, and after go mod tidy this repo's directive is still go 1.27.0. So:

• CI and the releaser keep reading go-version-file: go.mod.
• The release builder ghcr.io/goreleaser/goreleaser-cross:v1.27.1-1 already satisfies 1.27.0.
• There is no toolchain line or runtime image to move. This agent ships no image.

No doc in the repo states the old core pin, so no doc changes. Open #57's AGENTS.md states go.mod (1.27.0), which is still true.

structured-merge-diff/v7

go mod graph | grep structured-merge-diff/v7 prints nothing. go.mod keeps kustomize api/kyaml at v0.21.1 and kube-openapi at d427ff9ee9ad, so the issue's explicit downgrade wasn't needed.

Legacy

Nothing in this repo is labelled legacy. One item is labelled legacy in core: runtime.v0.TestResponse.status ([deprecated = true], under core's "Legacy flat fields" heading). runtime.go populates it next to the typed result. I left that alone on purpose:

• The deprecation is identical at v0.5.1, so the core move doesn't force anything.
• Core v0.19.4 still writes the field itself (agents/services/base_runtime.go TestResponse*/typedTestErrorResponse, runners/golang/formula.go).
• Dropping it would change what the agent returns on the wire, which the issue rules out of scope.

Proof that behaviour is unchanged

I ran a throwaway in-package probe test (not committed) on main (306c623) and on this branch against the same local Maven/Java fixture. It dumped to normalized JSON:

• GetAgentInformation (capabilities and README)
• Runtime Build, Test and Lint
• Tooling Build, Test, Lint, Add/RemoveDependency, GetProjectInfo and ListDependencies
• GetSemanticIndex (the tree-sitter analyzer)
• Code ListFiles and ReadFile
• an ApplyEdit dry run

The two dumps are byte-identical (11,387 bytes each).

What I reused

• The fleet's wave-1 floor as the issue gives it: core v0.19.4.
• The sibling approach in service-go-grpc#176 and service-go#138: bump, tidy, leave the go directive where core's declaration allows, and check SA1019 for legacy fields. service-go-grpc moved its test reads off TestResponse.Status. This repo's agent is a producer of that field, so the same move doesn't apply here (see Legacy).
• No code was copied. This repo needed none.

Gates run locally

• ci.yml boundary job, after go clean -testcache: go build ./..., go vet ./... and go test -count=1 -v ./.... 16 tests pass and 1 skips: TestAnyRegisteredBuilderServesConformantImageEvidence, which skips by design because no Builder is registered (same on main).
• The releaser.yml test job (go test -v ./...) is covered by the run above.
• The releaser.yml release job's build: goreleaser-cross:v1.27.1-1 build --snapshot --clean built all four CGO targets (darwin amd64/arm64, linux amd64/arm64).
• go mod tidy -diff is clean, go mod verify reports all modules verified, and there are no replace directives and no codefly pseudo-versions.

What I did not verify

• The real release --clean publish path: the Syft-generated archive SBOMs and the GitHub release upload. I ran build --snapshot only, because publishing is the coordinator's step.

• The release version bump. agent.codefly.yaml stays at 0.0.39. This repo bumps it in a separate release: vX commit when releasing (as with chore: pin core to v0.5.1 #69 → 306c623), so v0.0.40 is the coordinator's step.

• Lint. This repo has no lint gate in CI and no golangci config. A default golangci-lint v2.14.0 run reports 4 issues, and the same 4 are on main:

  • 3 × SA1019 on TestResponse.Status: one in runtime.go, two in agent_contract_test.go.
  • 1 × ineffassign at service.go:71.

  I didn't touch them, to keep this PR to what the core move forces.

• The real codefly CLI. I didn't load the built binary into it or run it end to end against a live workspace.

Overlap

Dependabot #73 bumps core to v0.7.0. This PR supersedes it, and #73 can be closed once this merges.

What I would file (not filed)

• One cleanup issue: settle the 4 pre-existing golangci-lint findings. That means fixing the dead store at service.go:71, then deciding whether the generic agent stops writing the deprecated TestResponse.status once the consumers in the CLI and Mind read only result.

🤖 Generated with Claude Code