[antoinetoussaint-byte]

Closes #21.

Moves github.com/codefly-dev/core from the pseudo-version v0.5.11-0.20260928114826-ae201a2288f1 to the released tag v0.19.4 and raises the go directive from 1.27.0 to 1.27.2. No Go source changes: core v0.19.4 didn't force any.

Changes, classified

Change	Classification	Why
go.mod: core v0.19.4 (released tag, no replace, no pseudo-version); go mod tidy refreshed indirects (grpc 1.83.2 → 1.84.0, otel 1.46 → 1.47, kube-openapi → d427ff9ee9ad, …)	fix	This is what the issue asks for. Every indirect bump comes from core v0.19.4's own requirements through MVS. None was chosen by hand.
go.mod: go 1.27.2, no toolchain line	fix	codefly publish runs govulncheck on the built agent and refuses the HIGH stdlib vulnerabilities fixed in 1.27.2. CI pins Go with go-version-file: 'go.mod', so CI follows without a workflow edit.
README.md: "builds against codefly-dev/core v0.3.31" → v0.19.4	fix	The doc stated a pin two moves stale.

No hacks.

What was reused, and what core changed

• Reused: core v0.19.4 as released, and the existing ci.yml unchanged. Its go-version-file already derives Go from go.mod, and it calls no core reusable workflows, so no @main → @v0.19.4 pin was needed. Its two actions are already pinned by SHA.
• Core API between the two pins. Every core symbol this agent imports kept its name, signature and value. That covers the runnable served-call constants the harness compiles in, resources.Runnable / RunnableExecution, agents, and the generated agent/builder/runtime protos. Evidence:
  • go build and go vet pass with no source edit.
  • The generated-harness goldens in pkg/generate pass without UPDATE_GOLDEN, so the generated harness is byte-identical.
• Opt-in additions this agent doesn't use. Core's runnable package gained submit completion with a callback address, tool exposure, required scope slots, and a refusal of unknown operation-policy fields. resources/runnable.go changed only Version: "0.0.1" → InitialVersion. Adopting any of these would be a behaviour change, which is out of scope here.
• sdk-go, sdk-go/workcontext and saas-sdk-go are not required by this module, so the issue's lines about them don't apply.
• agent.codefly.yaml is not changed. Its version stays 0.0.5. The release bumps it.

Verification

All three CI gates, run locally with Go 1.27.2 on darwin/arm64:

go build ./...    # ok
go vet ./...      # ok
go test -count=1 ./...
ok  github.com/codefly-dev/runnable-go               6.097s
ok  github.com/codefly-dev/runnable-go/pkg/agent     0.896s
ok  github.com/codefly-dev/runnable-go/pkg/generate  8.360s

The suite builds the agent binary and serves gRPC from it (serve_test.go). It also compiles generated packages with GOPROXY=off and runs a built harness as a process (pkg/generate).

Dependency hygiene:

• go mod graph | grep structured-merge-diff/v7 prints nothing. go.mod lists kustomize v0.21.1 and kube-openapi v0.0.0-20260721132016-d427ff9ee9ad, so no explicit downgrade was needed.
• go mod verify reports all modules verified.

Agent contract against core v0.19.4.

• No test in this repo calls agents/contract.Check, so I ran a throwaway test beside serve_test.go. It is not committed, because this move PR changes only what core forces.
• The test built the agent and dialed it over the TCP loopback handshake (CODEFLY_AGENT_UDS_PATH= empty). It then ran contract.Check on GetAgentInformation().Contract, first with no required capabilities and then with every capability in contract.Current().
• Both checks passed. The agent advertised protocol_version:1 capabilities:"container-recovery-scope/v1" startup_protocol_version:2, which is identical to core v0.19.4's contract.Current().

Not verified

• govulncheck was not run. It queries vuln.go.dev, and this task allowed no outbound traffic beyond git and the Go module proxy. The go 1.27.2 directive is what clears the stdlib findings, but codefly publish will be the first govulncheck run on this tree.
• codefly publish's release CI was not run. That includes the runnable-create conformance declared in agent.codefly.yaml, the cross-platform loader builds, and asset upload. I only ran the darwin/arm64 build and tests. GitHub CI covers linux build/vet/test.
• No end-to-end invocation by the CLI or module-runtime. The suite's harness-process tests are the closest thing to that.
• No lint. CI runs none, and this repo has no lint configuration.

How this repo is released

There is no release workflow in .github/workflows. Releases are cut by codefly publish in agent mode:

• agent.codefly.yaml has kind: codefly:runnable and release.owner: cli. In the CLI, cmd/publish/agent_release.go routes codefly:runnable to the loader-asset releaser, and workflow_release.go makes owner: cli mean the operator's machine publishes, not a workflow. Release preconditions require darwin/arm64.
• The history matches that flow:
  • PRs release: v0.0.2 #15, release: v0.0.4 #17 and release: v0.0.5 #19 are each a lone release: vX.Y.Z commit bumping agent.codefly.yaml, on a release-X.Y.Z branch. That is the PR landing in cmd/publish/landing.go.
  • Tags v0.0.2, v0.0.4 and v0.0.5 are signed annotated tags with message Version X.Y.Z, the exact string cmd/publish/release.go writes.

So after review and merge, the release is: on darwin/arm64, from a clean main, an operator runs codefly publish (patch bump, 0.0.5 → 0.0.6). It runs release agent CI, writes the version, commits release: v0.0.6, lands it through the release-0.0.6 PR, pushes the signed v0.0.6 tag, and creates the GitHub release with the loader assets. Don't hand-tag.

What I would file (not filed)

• runnable-go: serve_test.go should assert contract.Check(GetAgentInformation().Contract), so the contract proof above is a permanent test rather than a probe re-run on every core move.
• runnable-go#12 is overtaken. Its evidence ("git tag -l is empty", version: 0.0.1) predates the codefly publish releases above, and its question is answered: this repo is released as a published artifact by codefly publish with release.owner: cli. I would comment that and close it instead of opening anything new.
• release: v0.0.3 (release: v0.0.3 #16) has no tag. The merged commit f54ecf7 bumped the manifest, but git ls-remote --tags origin lists only v0.0.2, v0.0.4 and v0.0.5. It's harmless for the next release because publish bumps from max(manifest, latest tag). It is a hole in the release record that the coordinator may want to note.

🤖 Generated with Claude Code