[antoinetoussaint-byte]

Closes #138.

Moves the agent from core v0.17.0 to core v0.19.4, the fleet's current floor. It doesn't release anything: once this is merged, the release goes through releaser.yml (release: vX.Y.Z commit plus tag), done by the coordinator.

Changes and classification

Change	Class	Why
go.mod/go.sum: github.com/codefly-dev/core v0.17.0 → v0.19.4, then go mod tidy	fix	The owner's released tag, consumed as is. No replace, no pseudo-version. The transitive bumps (grpc 1.84.0, otel 1.47.0, x/sys, genproto, go-openapi/swag) are whatever core v0.19.4 requires, with no hand edits.
docs/PACKAGING.md: "pinned core v0.17.0" → v0.19.4	fix	The doc stated the old pin. I re-checked its claim against v0.19.4: core still bounds container removal with its own 10s timeout (runners/dockerrun/docker_runner.go:1114), so the sentence is still true with the new pin.
AGENTS.md: Go version "(1.27.0)" → "(1.27.2)"	fix	This was already stale on main: #129 raised the directive to 1.27.2 and left the doc behind.
chore(scout): AGENTS.md (CGO rule) and .claude/skills/release-go-agent: record that no goreleaser-cross image ships Go 1.27.2	hack, labelled	Review finding F1, already on main. The rule says the cross image's Go must match go.mod. goreleaser-cross has published nothing for 1.27.2 (newest is v1.27.1-3, whose build sets GO_VERSION=1.27.1; I checked ghcr.io and Docker Hub on 2026-10-13), so both pins stay where they are (releaser.yml v1.27.1-1, builder.go v1.27.0). The release build gets go1.27.2 through GOTOOLCHAIN=auto, which isn't hermetic. Package gets it through an explicit GOTOOLCHAIN. The docs now say so and name the exit: when the image is published, move both pins, run TestPackageRealCGO, and delete the note. The real fix belongs to goreleaser-cross, which owns publishing that image.

Nothing in the code changed. Every call site compiles and passes against v0.19.4 as written, so no adaptation was needed and none was invented. No shims.

Issue checklist

• Core v0.19.4, released tags only. This is the only go.mod. No replace, and no codefly pseudo-versions (gortk v0.2.0 is a tag). go mod verify passes and go mod tidy -diff is clean.
• sdk-go / workcontext / saas-sdk-go. None of them is required, directly or indirectly, so there's nothing to move.
• No structured-merge-diff/v7. go mod graph | grep structured-merge-diff/v7 prints nothing. Tidy resolves kustomize/api and kustomize/kyaml v0.21.1 and kube-openapi d427ff9ee9ad, so the issue's explicit downgrade was not needed and isn't applied.
• Go directive. Core v0.19.4 declares go 1.27.0, lower than this repo's go 1.27.2, so the directive doesn't move. CI already reads go-version-file: go.mod. The runtime image (go1.27.2), the builder Dockerfile and the goreleaser-cross pins are unchanged, because nothing forces them to change (see "Would file" for an existing drift).
• Legacy. Nothing labelled legacy is a code path in this repo. Two matches remain, on purpose:
  • pkg/service/effective_inputs_test.go:446: the variable named legacy is an agent that doesn't implement GetEffectiveInputs. The test asserts that core's ciinputs.Discover falls back conservatively and authorizes no cache reuse for it. Core v0.19.4 still has that fallback (ciinputs/inputs.go:119, "unsupported declaration"), so the test covers a current safety contract. Deleting it would lose coverage without removing any legacy code.
  • templates/factory/flake.nix.tmpl: nixpkgs.legacyPackages is the name of the Nix API.

Reused

• The released core v0.19.4 tag and the pins the issue names.
• The repo's own gates from ci.yml and .claude/skills/verify-changes: TestManifestGuardRender (the manifest-guard render), the recipe tests checked by core's services.VerifyDockerBuildPlan, TestPackageRealCGO, and the runtime-image reproducibility steps.
• I didn't need anything from service-go-grpc#176, since no core API change reached this repo's call sites.

Verification (all run locally on darwin/arm64, Go 1.27.2)

• go build ./..., go vet ./..., go test -count=1 ./...: all pass. This includes the root policy tests (workflow SHA pins, Dependabot grouping, AGENTS.md budget). The releaser's go test -v ./... runs the same packages.
• Manifest guard, determinism half: TestManifestGuardRender rendered twice with the CI env (RESTRICTED_PORTABLE_V1) gave identical trees. The tree is also byte-identical to the same render from origin/main at core v0.17.0, so the core move changes no rendered manifest.
• Recipe rendering: TestBuildEmitsRecipePlan, TestBuildxRecipeOverGRPC and the other recipe/Dockerfile template tests pass. The emitted plans pass core's VerifyDockerBuildPlan.
• SERVICE_GO_PACKAGE_TESTS=required go test -race -count=1 -v -timeout 15m ./pkg/builder -run TestPackageRealCGO: PASS (48.6s). linux/amd64 did a real cross build through goreleaser-cross (45.7s) and darwin/arm64 built natively (2.6s). The first attempt failed only because the local Docker daemon was unreachable, and it passed once the daemon was up.
• runtime-image job: built with CI's pinned BuildKit (moby/buildkit@sha256:2f5a…). The smoke checks pass (go1.27.2, GOTOOLCHAIN=local, tools present). The multi-platform OCI build reproduces the lock digest sha256:341506e8…0732. The pinned ref passes the anonymous docker manifest inspect check. Trivy reports no HIGH/CRITICAL findings.

Not verified

• The go1.27.2 download inside goreleaser-cross during v0.0.69. GoReleaser hides go output on success, so the release log doesn't show it. It's inferred from the image setting no GOTOOLCHAIN and Go defaulting to auto.
• The goreleaser-cross image pull. ghcr.io/goreleaser/goreleaser-cross:v1.27.0 was already in my local Docker cache, so TestPackageRealCGO exercised the cross build but not the pull. CI's cold cache covers the pull.
• Trivy on amd64. It ran on the arm64 build of the runtime image; CI scans amd64.
• ./pkg/runtime nix integration. It skips without a sibling core checkout, and running it would make Nix fetch nixpkgs over the network, which this task rules out. CI doesn't run it either. This PR doesn't touch pkg/runtime, but core's runners underneath it did change between v0.17.0 and v0.19.4, so this path is unverified.
• The release itself: no GoReleaser run, no install through core's downloader. Both happen at tag time.
• The manifest guard's ownership-concept scan. It lives in codefly-dev/.github and I didn't reproduce it locally. Since the render is byte-identical to main's, it should give the same result, but the PR's CI run is what checks it.

Would file (not filed, per instructions)

1. goreleaser-cross pins lag the Go directive: handled in this PR by the chore(scout) commit (review finding F1), see below.
2. build(core): adopt core v0.17.0 #129 committed a 24 MB binary, base/code/codefly-base. It looks accidental.

🤖 Generated with Claude Code