release: fuzeagent images ecae85cb9cec

[github-actions]

Automated GitOps image-tag bump. Images built from CI-tested code.

[izzywdev]

Automated GitOps release

[izzywdev]

Conflict resolved — but this PR is the reason prod is running the wrong images

Not merging it myself: main here is deploy-on-push and this bump moves five production images. That is an owner action inside a deploy window.

What happened

Two releases went out seven minutes apart and the second one lost:

	commit	bump PR	outcome
#144	51f1278 — 4-pod standard	#152	merged
#148	ecae85c — a2a.inClusterUrl (contract v1.2.0)	#153 (this one)	stranded

release.yml branches its bump from the release commit, not from current main. #153 branched off ecae85c, whose values-prod.yaml still read e2d7d1c2b55a. #152 merged first, rewriting the same five tag: lines, so gh pr merge --admin on #153 died with "the merge commit cannot be cleanly created" (run 31414731591, step 11).

Everything before that step succeeded. All five images were built and pushed at ecae85cb9cec. Only the pin failed.

Consequence

main is pinned to 51f12786811a — the build from one commit before inClusterUrl. So a2a-shared in prod does not carry contract v1.2.0, and the per-product A2A pods now in flight (FuzeService#36, FuzeSales#48, FuzeBI#31, FuzePlan#177) are built against a feature the shared server does not have.

The ordering makes this worse than a missed release: the run failed, so nothing claimed success — but the failure was in a step whose only job is bookkeeping, long after the artefacts were already published. Green images, stale pin, red run nobody read.

What I changed

Merged origin/main into this branch and resolved all five conflicts in favour of ecae85cb9cec. ecae85c is a descendant of 51f1278, so the newer build strictly supersedes.

Verified the resolution is not hiding anything: git diff ecae85c origin/main on these two files shows the tag bump and nothing else, and the net diff of this branch against main is exactly the five tag: lines.

Root cause, not fixed here

The bump step will race again on the next back-to-back release. It should git fetch origin main and apply the sed to current main rather than to the release commit's tree — and if it must branch from the release commit, gh pr merge --auto instead of a bare --admin so a conflict blocks rather than strands. Worth a separate PR; I have not touched release.yml.

---

Generated by Claude Code

[izzywdev]

Addendum — read before merging: this PR is no longer only a tag bump

Minutes after I pushed the conflict resolution, governance-sync pushed 88e12ba onto this branch:

.claude/agents/backend-engineer.md    |  2 ++
.claude/agents/contract-designer.md   |  2 +-
.claude/agents/test-engineer.md       |  2 ++
agent-templates/sync/role_loader.py   | 20 +++++++++++++++++++-

role_loader.py is runtime code, and it is not in image ecae85cb9cec. The commit carries [skip ci], so merging will not rebuild either. Merging as-is therefore lands source on main that no published image contains, while simultaneously pinning prod to an image built before it — the pin would be accurate about the images and wrong about main.

Nothing here is dangerous; the next release reconciles it. But it is worth naming, because a release-bump PR is supposed to be exactly five lines and the merge diff is the only place that invariant is visible. governance-sync has no notion of what kind of PR it is reconciling, so it will do this to every future release bump too.

If you want the clean thing: merge this for the pin, and let the following release pick up role_loader.py properly with an image built from it.

---

Generated by Claude Code