home-network-k3s-impl/docs/plans/pm-agent-issue-to-pr.md

# Plan: an in-cluster AI Program Manager that turns Gitea issues into pull requests

**Status:** authored, gate-checked offline, **nothing deployed**. The image has never been
built or pushed; no part of this has run in the cluster.
**Owner:** Program Manager. **Serves:** R-SEC-02 (least privilege), R-GITOPS-02 (declared
delivery). **Implementation:** [`platform/pm-agent/`](../../platform/pm-agent/),
[`infra/agent/`](../../infra/agent/),
[`platform/kyverno/admission/pm-agent-job-shape.yaml`](../../platform/kyverno/admission/pm-agent-job-shape.yaml).

## What was asked for

A service running in the k3s cluster that hosts an AI agent which reads issues reported in
the Gitea project and spins up other agents to fix the codebase, following the required PR
workflow. It uses an Anthropic commercial subscription. It runs as the Program Manager
persona specified in the repository. It reacts to issue creation and to comments within
issues, and the agents it spins up are assigned the ticket, with all context and
correspondence flowing through the ticket and the PR process.

## The shape, in one paragraph

A single-replica **dispatcher** (`pm-dispatch`) polls the Gitea issue list. For any issue
whose newest activity was not its own, it hands the whole thread to the model under the
**Program Manager persona** — with no tools — and gets back one decision:
`implement` / `revise` / `comment` / `decline`. It validates that decision, creates **one
worker Job per assignment** from a committed template, and posts the PM's reply on the
issue. Each **worker** (`pm-worker`) clones the repository, checks out the branch the PM
named, re-reads the live issue thread, runs a full Claude Code session against `CLAUDE.md`,
runs `./ci/gate.sh`, and only then commits, pushes, opens the pull request and reports back
on the issue. Both halves are one image; neither takes a command-line argument.

---

## Decisions, and what was rejected

### 1. Poll the Gitea API; do not receive webhooks

Webhooks were the first design. Rejected for three reasons, in increasing order of weight:

- **Gitea's own SSRF guard.** Webhook targets are filtered by `[webhook]
  ALLOWED_HOST_LIST`, whose default posture excludes private and loopback addresses — and
  every in-cluster target is one. Receiving webhooks means widening a security setting on
  the git host so it can call into the cluster. *(Stated as the reason for rejection, not as
  a measured fact about this Gitea: nothing here queried that setting. Anyone reviving
  webhooks should measure it first.)*
- **A missed delivery is gone.** A webhook that arrives during a pod restart or a Flux roll
  is lost, and the issue then sits unanswered forever with nothing in any log explaining
  why. A poll cannot miss an event because it does not consume events — it reads current
  state.
- **It would need inbound reach.** A receiver means a Service, an ingress allow from the
  `gitea` namespace, and a shared secret to verify signatures. Polling needs none: this
  namespace takes **no ingress at all**, which is a materially smaller surface for a
  workload whose purpose is running model-authored code.

Cost: up to `PM_POLL_INTERVAL_SECONDS` (60s) of latency. For a home platform whose
alternative is "a human gets to it this evening", that is not worth a security exception.

### 2. The issue thread is the state. There is no database

Rejected: a PVC holding a per-issue cursor, or a ConfigMap of last-seen comment IDs.

The trigger is *act iff the newest thing in this thread was not written by me*. Because the
PM always answers in the thread, acting makes the thread quiet again until somebody else
speaks. That gives three properties a cursor file does not have: it survives restart,
reschedule and rebuild with **no recovery path to get wrong**; it is **readable** by the
operator in the place they are already looking; and it creates **no R-STATE-03 obligation**,
because there is no irreplaceable state to back up.

One consequence is load-bearing and easy to get backwards: **the Job is created before the
comment is posted.** If the Job exists and the comment fails, the next cycle re-triggers,
finds the Job active, and does not duplicate it — and the worker posts its own comment when
it finishes. The other order would leave the PM's own comment as the newest in the thread
with no work running, so the trigger would never fire again and the issue would be silently
abandoned holding a promise.

A second consequence: exactly one replica, `strategy: Recreate`. Two dispatchers would both
see the same untouched thread in the same window and both act on it — two decisions, two
comments, two branches. `Recreate` extends that to rollouts, where the default
`RollingUpdate` would briefly run two.

### 3. Two roles, and the PM holds no tools

Rejected: one agent that triages *and* implements.

The PM runs `claude --print --tools ""` against a JSON schema. It cannot run a command, read
a file or reach the network; it returns one JSON object. The dispatcher then validates every
field — the action against a fixed set, the branch against `CLAUDE.md` §4's pattern, `revise`
against the branch that actually carries that issue's work, the brief against being empty —
and refuses rather than repairing (a silently rewritten branch name is a branch the PM's own
comment then misnames).

That gives three independent layers between a hostile issue comment and the cluster: the
model holds no tools, the dispatcher accepts only a validated vocabulary, and admission
constrains the one object it may create. Any one failing leaves two. It matters because the
input is text written by whoever can reach the repository, and an issue saying "ignore your
instructions and push to main" has to be ordinary data. **Nothing in this path executes
text.**

### 4. Follow-ups re-read the thread; sessions are not resumed

Rejected: persisting each assignment's session and resuming it with `--resume` when a new
comment arrives.

A `revise` worker checks out the existing branch, reads what is already on it
(`git log`/`git diff` against the base) and re-reads the **live** thread, which may have
moved on since any brief was written. That is stateless and idempotent: no transcript to
store, nothing to go stale, and the context is always current. The cost is re-reading, which
is cheap compared with a resumed session whose stored context disagrees with the thread.

### 5. The worker runs the real gate, in the real toolbox

`CLAUDE.md` §3 is explicit that only the pinned toolbox result counts — gating without
`promtool` and the rest produces a false rc 3. So the `agent-runner` image is built **FROM**
the dev toolbox rather than assembling a subset of the toolchain. The cost is size (~2 GiB
for an image that needs neither ansible nor OpenTofu); the alternative costs drift, and the
first time the two toolchains differed a worker's "gate green" would stop meaning the gate's
green while still reading as a pass.

Two stages cannot run in-cluster, and the worker's acceptance rule names them exactly:

- `spec-immutability` — **the sibling spec repo has no git remote.** It exists only on the
  operator's workstation (measured: `git remote -v` in `../home-network-k3s` prints
  nothing), so no in-cluster process can check it out. `CLAUDE.md` §3 already names this skip
  as expected and tolerated. The worker also cannot *modify* the spec, because it is not
  there.
- `gitea-settings` — needs the admin-scoped settings token, which a worker must not hold.

A worker accepts **rc 0**, or **rc 3 whose "Stages that did not run" line names nothing but
those two**. Any other skip is a refusal. The commit happens **before** the gate, because
`ci/touched-requirements.sh` derives its subset from `git diff BASE...HEAD` and the lint/L0
scans enumerate `git ls-files` — gating a dirty tree examines almost none of the change and
reports a cheerful PASS over an empty subset, which is the exact false green that script's
header records. The commit is local to an ephemeral container and is discarded with the pod
if the gate refuses it.

### 6. Subscription auth, and the two variables that must stay unset

The service authenticates with an Anthropic **subscription** (Pro/Max/Team/Enterprise) via
`CLAUDE_CODE_OAUTH_TOKEN`, minted by `claude setup-token` — a **one-year** OAuth token that
the command prints and saves nowhere.

Three facts that shape the implementation:

- **Credential precedence.** `ANTHROPIC_API_KEY` and `ANTHROPIC_AUTH_TOKEN` both rank
  **above** `CLAUDE_CODE_OAUTH_TOKEN`. A stray or empty value in either silently takes over,
  and the failure looks like a model outage rather than a credential mix-up. The image sets
  neither; `pm-worker` unsets both before every session; the admission policy refuses a Job
  that tries to set them.
- **Bare mode does not read it.** `--bare` ignores `CLAUDE_CODE_OAUTH_TOKEN`, so neither
  entrypoint may use that flag however much faster it starts.
- **No expiry warning exists.** Claude Code's "login expires in 3 days" notice fires only
  for an interactive login, never for this variable. When it lapses every session fails at
  once. That is why the runbook carries the rotation procedure and asks for the mint date to
  be recorded.

Usage counts against the subscription seat's own limits, shared with every other use of that
seat — which is the real reason `PM_MAX_ACTIVE_WORKERS` defaults to 2 rather than a RAM
calculation alone.

### 7. The admission policy is the boundary; RBAC is only its necessary half

Kubernetes places **no `use` check** on a Pod's `serviceAccountName`, so "may create Jobs in
this namespace" is "may run arbitrary code as the most privileged identity in it". The
dispatcher creates Jobs. Answered twice over:

- **Nothing to escalate to.** `pm-agent-worker` is bound to no Role, and the Job template
  mounts no token (`automountServiceAccountToken: false`). The egress policy does not include
  the API server either, so `kubectl` — present because the gate's toolchain needs it — is
  inert.
- **The shape is constrained at the API server.** `pm-agent-job-shape` is `Enforce` with
  `failurePolicy: Fail` (a boundary an overlay can downgrade to Audit is not a boundary), and
  it deliberately starts with all six rules the sibling policy needed four revisions to
  reach: the committed shape, exactly one container with no args, only `workspace`/`tmp`
  **emptyDir** volumes, no init or ephemeral containers, only the committed env **names**, no
  `envFrom`.

`platform/kyverno/tests/pm-agent/` proves each refusal offline — 28 assertions, all passing
under the pinned CLI — including the two that a careless policy admits: a second container
while `containers[0]` is perfectly compliant (a Kyverno array pattern is satisfied by one
matching element), and a volume **named** `workspace` whose source is a `hostPath`.

### 8. Not a catalog ServiceDefinition

`schemas/servicedefinition.schema.json` has `additionalProperties: false` and no way to
express a ServiceAccount, a Role, a `command`, a Job template or an admission policy. This
service is mostly those things. It is therefore hand-authored under `platform/` with its own
non-gating Flux Kustomization — the `crafty`/`headlamp`/`backup` pattern — rather than being
forced through the renderer. The one catalog change it needs is an `inClusterClients` entry
on `gitea`, so that Gitea's own default-deny admits the agent's namespace on tcp/3000; the
golden was re-rendered with the canonical command.

---

## Threat model

The input is text that anyone who can reach the repository can write. The thing acting on it
holds a git write token and can author code. So:

| concern | what answers it |
|---|---|
| a prompt-injected issue tells the PM to push to `main` | the PM holds no tools; `pm-worker` refuses `PM_BRANCH=main` before anything runs; branch protection rejects the push regardless |
| …tells it to merge, or to post `/approve-override` | the service makes no merge call and no review call; the bot account is a non-admin collaborator, so the override would be rejected by `ci/approval-policy.sh` on live permission |
| …tells it to exfiltrate a secret | egress is this Gitea and tcp/443 only; the worker's clone/push host is validated against an allowlist baked into the image; `CLAUDE.md` §6's no-plaintext-secrets rules are in both the persona and the worker rules |
| …tells the dispatcher to create a privileged Job | the dispatcher only ever renders the committed template; admission re-checks it fail-closed |
| the model returns a malformed or hostile decision | validated field by field, and refused rather than repaired |
| a worker loops or wedges | `--max-turns`, `--max-budget-usd`, `activeDeadlineSeconds: 5400`, `backoffLimit: 0` |
| a backlog stampede the moment credentials work | `PM_MAX_ACTIVE_WORKERS=2`, `PM_MAX_NEW_WORKERS_PER_CYCLE=1`, `PM_ISSUE_COOLDOWN_SECONDS=900`, and `PM_REQUIRE_LABEL` for a staged rollout |
| an unreviewed change reaches `main` | it cannot: the gate is a required status check, `block_admin_merge_override: true`, and a sensitive-path PR needs a non-author review the bot cannot supply |
| **the worker's own credentials** | **not defended.** The session shares the container and uid with the wrapper and can read its environment. Bounded by scope (one repository, write, no admin) and by egress, not by isolation |
| **`world:443` is wider than one API host** | **not defended.** Narrowing needs `toFQDNs`, which needs Cilium's DNS proxy verified first. Tracked below |
| **a `write` collaborator can merge** | **not defended by the credential.** No Gitea scope separates push-and-open-PR from merge. Bounded by the code making no merge call |

## Verified, and not

**Verified offline, with numbers:** `kyverno test platform/kyverno/tests/pm-agent` → 28/28
under the pinned CLI (the first run was 27/28 and caught a real defect: the volume rule
denied a valid `emptyDir: {}`); `check-jsonschema` on the changed ServiceDefinition; the
canonical render reproduces `apps/wave-0/gitea.yaml` with the new policy in it; `bash -n`
and `ast.parse` on the two entrypoints; `PM_SELFTEST=1 pm-dispatch` → 26 assertions, 0
failures; `infra/agent/probe-validation.sh` → **17 refusals, 0 failures** against
`pm-worker`'s input guards, including the three that matter most (a redirected git host, a
reachable-but-wrong one, and `main` as the branch). **`./ci/gate.sh` → exit 3 (UNDETERMINED), with
`gitea-settings` the one stage that did not run** — no `SETTINGS_API_TOKEN` on this
workstation — and every other stage green, `spec-immutability` included. rc 3 is not a pass.
The gate also refused an earlier revision of this change twice, both times correctly; see
the handoff entry.

**Not verified — nothing has run.** The image has never been built (so the node/npm layer,
the Claude Code install and the in-image verification are unexercised), never pushed, never
pulled. No pod has started. No issue has been triaged, no Job created, no branch pushed, no
pull request opened. The admission policy has not been tested against a live API server, the
network policies have not been exercised, and neither credential exists. Every statement
about runtime behaviour in this document is a design claim, not a measurement.

## Follow-ups, in the order they are worth doing

1. **Make the registry pullable, THEN build, push, pin.** Measured after the merge, and
   neither half is declared anywhere in this repository
   (`decisions/2026-10-05-pm-agent-registry-pull-prereq.md`):
   (i) the nodes resolved the registry hostname to the WAN IP and failed TLS against the
   router's `CN=%D` placeholder certificate — **diagnosed and fixed** by pinning
   `gitea.{{ k3s_base_domain }}` to the Gateway VIP in `node_baseline_hosts_pins`, the same
   pin the Keycloak issuer already carries, applied by
   `ansible-playbook playbooks/node-baseline.yml -e k3s_hosts=k3s_prod --tags hosts`;
   (ii) the pull is still unauthenticated and no `imagePullSecret` exists in the tree — with
   the credential decision now being local Gitea accounts with PATs, that means a
   `dockerconfigjson` for an account whose token carries `read:package`. Only then does the
   digest matter. Operator runs `infra/agent/build-image.sh`, pushes, and one PR replaces both
   placeholder digests. Expect the build itself to need iteration too: the nodejs module
   stream and the npm install have never run against this base. The same two blockers sit in
   front of `conformance-runner`, which shares the registry path and has never been pulled.
2. **Create the credentials** per `pm-agent-credentials.sops.yaml.example`, and **verify the
   bot's permission is `write`, not `admin`** — that measurement is the control that keeps
   the agent out of its own approval gate.
3. **First run with `PM_DRY_RUN=true` and `PM_REQUIRE_LABEL=agent`**, on one issue written
   for the purpose. Read what the PM says before letting it write anything.
4. **Tighten the admission image pin** from the `@sha256:*` wildcard to the literal digest.
   One line, reviewed.
5. **Narrow `world:443` to `toFQDNs: api.anthropic.com`** — after verifying Cilium's DNS
   proxy is enabled and that the model still answers through it.
6. **Observability.** There is no metrics endpoint and no alert. The namespace's default-deny
   would drop a scrape from `monitoring`, so adding metrics means adding the port *and* its
   additive ingress allow — the lesson of
   `decisions/2026-10-04-oauth2-sidecar-metrics-scrape-netpol.md`. A useful first alert is
   "the dispatcher has not completed a cycle in 15 minutes", and note that a bare `up{}`
   makes an alert self-silencing: use `up == 1`.
7. **A conformance test for the real boundary.** The L0 Kyverno suite proves the policy
   refuses; nothing proves the API server does. That is an L2 test, and it needs a cluster.