---
date: 2026-10-31
branch: chore/pm-agent-digest-99
title: Pin pm-agent dispatcher and worker to the agent-runner digest built from PR #99's merge
---

## What changed

- `platform/pm-agent/deployment.yaml`: the dispatcher `image:` moves from
  `agent-runner@sha256:df36d9b7…` (images run 383) to
  `agent-runner@sha256:14a42ba8281ecd98005f5d99ecda4fb729104c783b01584097c32e104ced1bb2`.
  `config-generation` goes from "4" to "5" so the pod rolls.
- `platform/pm-agent/configmap.yaml`: `PM_WORKER_IMAGE` gets the same digest. A comment line
  records where it came from. The `# renovate-digest:` marker still sits directly above both
  values.
- No other values changed. `PM_DRY_RUN` stays "false". `PM_DECISION_MAX_TURNS` is not set, so
  it keeps its in-code default of 1. No `*.sops.yaml` was touched.

## What I verified

- PR #99's merge commit is `466f63ec3c3df968a1dab25a8811dcd41961efde` (origin/main HEAD at
  branch time).
- The Gitea Actions tasks API shows the `images` workflow (images.yaml) on that commit as
  **run 394** (task 643), with event `push` and status `success`.
- I resolved the digest read-only from the registry by HEADing the manifests with OCI and
  Docker Accept headers. Both `agent-runner:sha-466f63ec3c3d` and `agent-runner:main` returned
  `200`, an `application/vnd.oci.image.manifest.v1+json` content type, and
  `docker-content-digest: sha256:14a42ba8281ecd98005f5d99ecda4fb729104c783b01584097c32e104ced1bb2`.
  The two are identical.
- Toolbox gate: the rc and skipped stages are in the PR description.

## What I did NOT verify

- That the dispatcher actually rolls to the new digest after merge, and that Flux applies it.
  Flux's `lastAppliedRevision` and the pod's image were not checked. That is post-merge work.
- That the new image surfaces the triage failure's real cause. It will show only on the next
  failing triage, in the dispatcher log.
- That admission (rule 7, `imagePullSecrets`) admits worker Jobs from this digest. The
  template comes from `infra/agent/` at PR #99's merge, which still carries the
  `imagePullSecrets` entry, but no Job was created to prove it.
- I did not run the image's own selftest against this digest.