release: automate the fullsend-ai/agents harness image digest repin after each release

[waynesun09]

Problem

The container image every CI agent run uses is decided solely by the image: digest pins in fullsend-ai/agents/harness/*.yaml (fullsend-sandbox for triage/retro/prioritize/scribe, fullsend-code for code/review/fix). Nothing updates those pins:

• release.yml builds and tags :X.Y.Z images and tag-agents tags agents main as-is; resolveAgentsRef() makes release CLI builds fetch agents@tags/<version>, so whatever pins sit on agents main ship to that version's users.
• agents' Renovate manages only github-actions and git-submodules, not docker digests.
• .fullsend/config.yaml has no image field and FULLSEND_SANDBOX_IMAGE is a local-dev-only knob.

So any Containerfile change under images/sandbox or images/code that a runtime needs reaches users only after a manual repin PR in agents, and the design has an inherent one-release lag (an agents tag can never reference its own release's images, because tag-agents runs in the workflow that builds them).

Evidence

• feat(#6571): add xai-vertex provider to the pi runtime #6572 vendored the pi-xai-vertex extension into the sandbox image (shipped in v0.37.0, rev 84c8bbbb). The agents pins still pointed at builds of the aborted 08-23 v0.37.0 attempt (rev 1f027be5), so the first live Grok-on-pi run — fullsend-ai/pi-xai-vertex run 32880776870 — selected xai-vertex/xai/grok-4.6 correctly (via feat(#6581): per-agent runtime, model and effort on agents: entries #6583's per-agent agents: settings) and then died: Failed to load extension "/usr/local/share/pi-extensions/xai-vertex": Extension path does not exist.
• Manual fix: chore: repin harness images to the v0.37.0 release builds (ship the xai-vertex pi extension) agents#1025 (repin to the :0.37.0 digests). Previous manual bump: Enable fleet agents on the pi runtime agents#935.

Goal

After a fullsend release, the agents harness pins move to that release's image digests without a human remembering to do it, keeping digest immutability.

Options (not decided)

1. Release-driven PR: a repin-agents-images job in release.yml (after sandbox-images finishes for the tag) resolves ghcr.io/fullsend-ai/fullsend-{sandbox,code}:X.Y.Z to digests (skopeo inspect / docker buildx imagetools inspect), rewrites the seven image: lines and opens a PR against agents (bot-authored, DCO-signed). Merging is still a human step but the PR is never forgotten; the one-release lag remains.
2. Renovate in agents: a custom regex manager over harness/*.yaml with pinDigests: true tracking the :0.X tag. Automates the PR; still one release behind; no fullsend-side change.
3. Runtime-resolved image: harness pins by name only and fullsend selects the tag from its own build version (:X.Y.Z for release CLIs, :dev/:latest for main), mirroring resolveAgentsRef(), verifying the tag's digest at pull. Removes the lag entirely but changes the harness contract and gives up static digests in the harness file.

Whichever lands, docs/ should state the convention (pins reference release-tagged digests, never main :latest) and the release checklist should stop listing the manual repin.

Acceptance

• A release of fullsend results in an agents PR (or an automatic resolution) that points every fullsend-sandbox/fullsend-code harness pin at that release's digests, with the revision label verified to equal the release commit.
• The manual step is removed from the release-gate practice page / release docs.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 6:41 PM UTC · Completed 6:46 PM UTC

Commit: efbad46 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.03

[fullsend-ai-triage]

Triage Summary

Severity: High — demonstrated production impact (pi-xai-vertex extension failure).

Design decision needed: The issue presents three viable options with different trade-offs (release-driven PR, Renovate regex manager, runtime-resolved image). A design decision should be made before implementation.

Related issues:

• release: validate-agents startup failure (caller permissions) + agents gate validates a different tree than tag-agents tags #6512 (open) — addresses the agents gate tree-vs-tagged-tree divergence in the same release workflow; work on this issue should be coordinated with release: validate-agents startup failure (caller permissions) + agents gate validates a different tree than tag-agents tags #6512 to avoid conflicting release.yml changes.
• Add smoke-test gate before promoting fullsend-sandbox to :latest tag #3409 (open) — smoke-test gate before promoting sandbox images; a complementary concern for image quality before repin.

⚠ Workflow changes required: The most likely implementation path (option 1) adds a job to .github/workflows/release.yml. The code agent cannot modify workflow files under current permissions — this will require a manual PR or maintainer action.

Proposed test:

# After release workflow completes for tag vX.Y.Z:
# 1. Resolve expected digests:
#    skopeo inspect ghcr.io/fullsend-ai/fullsend-sandbox:X.Y.Z
#    skopeo inspect ghcr.io/fullsend-ai/fullsend-code:X.Y.Z
# 2. Verify a PR was opened against fullsend-ai/agents updating
#    all image: fields to the new digests
# 3. Verify release docs no longer list a manual repin step

---

Labels: Adding needs-design because the issue explicitly presents three undecided implementation options, and priority/high because stale pins caused a demonstrated production failure.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance