chore(deps): update helm release authentik to v2026.8.4

Merge pull request 'docs(plans): kuma-sync controller design and plan' (#1341 ) from docs/uptime-kuma-plan into master
Reviewed-on: k.renner/homelab#1341
2026-10-19 02:02:07 +00:00 · 2026-10-18 21:05:14 +00:00 · 2026-10-18 23:03:26 +02:00 · 2026-10-18 20:53:19 +00:00 · 2026-10-18 22:48:31 +02:00 · 2026-10-18 20:43:42 +00:00
219 changed files with 5676 additions and 911 deletions
@@ -101,7 +101,7 @@ steps:
        bash scripts/ci/make-diag-kubeconfig.sh

  - name: alert-triage-agent
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    environment:
      CLAUDE_CODE_OAUTH_TOKEN:
        from_secret: claude_code_oauth_token
@@ -35,25 +35,25 @@ when:
 steps:
  - name: model-selection-tests
    depends_on: []
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    commands:
      - sh scripts/ci/test-model-selection.sh

  - name: pr-review-mistral-tests
    depends_on: []
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    commands:
      - sh scripts/ci/test-pr-review-mistral.sh

  - name: promtool-rules-guard-tests
    depends_on: []
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    commands:
      - sh scripts/ci/test-promtool-rules.sh

  - name: yaml-citations-guard-tests
    depends_on: []
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    commands:
      - sh scripts/ci/test-yaml-citations.sh

@@ -0,0 +1,47 @@
+when:
+  # Deploy only on master (merge) + manual — never auto-deploy from a branch.
+  - event: push
+    branch: master
+    path:
+      - "ansible/roles/uptime-kuma/**"
+      - "ansible/plays/install-uptime-kuma.yml"
+      - ".woodpecker/deploy-uptime-kuma.yml"
+  - event: deployment
+    evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "deploy-uptime-kuma"'
+  - event: cron
+    cron: uptime-kuma-token-renew
+
+timeout: 30
+
+steps:
+  - name: renew-openbao-token
+    image: gitea.renner.uno/gitea_admin/ci-ansible:2026-10-18
+    environment:
+      VAULT_TOKEN:
+        from_secret: openbao_uptime_kuma_token
+    commands:
+      - 'curl -sSf -X POST -H "X-Vault-Token: $VAULT_TOKEN" https://openbao.renner.uno/v1/auth/token/renew-self -o /dev/null'
+
+  - name: deploy-uptime-kuma
+    image: gitea.renner.uno/gitea_admin/ci-ansible:2026-10-18
+    when:
+      - event: [push, deployment]
+    environment:
+      ANSIBLE_FORCE_COLOR: "true"
+      ANSIBLE_HOST_KEY_CHECKING: "false"
+      ANSIBLE_ROLES_PATH: "../roles:./roles"
+      SSH_PRIVATE_KEY:
+        from_secret: ssh_private_key
+      VAULT_PASS:
+        from_secret: vault_pass
+      VAULT_TOKEN:
+        from_secret: openbao_uptime_kuma_token
+    commands:
+      - mkdir -p ~/.ssh
+      - echo "$SSH_PRIVATE_KEY" | base64 -d > ~/.ssh/id_ed25519
+      - chmod 600 ~/.ssh/id_ed25519
+      - printf "Host *\n\tStrictHostKeyChecking no\n\tUserKnownHostsFile /dev/null\n" > ~/.ssh/config
+      - cd ansible
+      - echo "$VAULT_PASS" > .vault_pass && chmod 600 .vault_pass
+      - export ANSIBLE_VAULT_PASSWORD_FILE=.vault_pass
+      - ansible-playbook -i inventory/ plays/install-uptime-kuma.yml -v
@@ -26,7 +26,7 @@ steps:
    # fetch-models.sh response mapping. No cluster, no secrets, no network — the
    # ci-claude image just provides sh + jq. Keeps the flag-injection regression
    # test from rotting (it exercises the exact injection shapes).
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    commands:
      - sh scripts/ci/test-model-selection.sh

@@ -62,7 +62,7 @@ steps:
      - bash scripts/ci/make-diag-kubeconfig.sh

  - name: issue-fix-agent
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    environment:
      CLAUDE_CODE_OAUTH_TOKEN:
        from_secret: claude_code_oauth_token
@@ -70,7 +70,7 @@ steps:
    # this step is skipped — otherwise we'd fork-bomb PRs.
    when:
      - branch: master
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    environment:
      CLAUDE_CODE_OAUTH_TOKEN:
        from_secret: claude_code_oauth_token
@@ -30,7 +30,7 @@ when:

 steps:
  - name: update-audit-agent
-    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.296
+    image: gitea.renner.uno/gitea_admin/ci-claude:2.1.302
    environment:
      CLAUDE_CODE_OAUTH_TOKEN:
        from_secret: claude_code_oauth_token
@@ -0,0 +1,15 @@
+---
+# Deploy Uptime Kuma to the NetBird VPS
+# Usage: ansible-playbook -i inventory/ plays/install-uptime-kuma.yml
+#
+# Prerequisites:
+# - netbird-server play applied (docker, Traefik on netbird_netbird)
+# - OpenBao homelab/infrastructure/uptime-kuma with keys username, password
+# - VAULT_TOKEN in the environment (policy: uptime-kuma-vps)
+# - DNS for kuma.renner.uno pointing at the VPS
+
+- name: Deploy Uptime Kuma
+  hosts: netbird_server
+  become: true
+  roles:
+    - uptime-kuma
@@ -0,0 +1,11 @@
+---
+uptime_kuma_version: "2.5.6"
+uptime_kuma_host: kuma.renner.uno
+# Not routed yet; reserved for the public status page.
+uptime_kuma_status_host: uptime.renner.uno
+uptime_kuma_dir: /opt/uptime-kuma
+uptime_kuma_traefik_network: netbird_netbird
+
+uptime_kuma_openbao_url: https://openbao.renner.uno
+uptime_kuma_openbao_mount: homelab
+uptime_kuma_openbao_path: infrastructure/uptime-kuma
@@ -0,0 +1,46 @@
+// Creates the Uptime Kuma admin user on first start; exits 0 if already set up.
+// Credentials come from KUMA_SETUP_USERNAME / KUMA_SETUP_PASSWORD only.
+const { io } = require("socket.io-client");
+
+const username = process.env.KUMA_SETUP_USERNAME;
+const password = process.env.KUMA_SETUP_PASSWORD;
+if (!username || !password) {
+    console.error("KUMA_SETUP_USERNAME and KUMA_SETUP_PASSWORD must be set");
+    process.exit(2);
+}
+
+const socket = io("http://127.0.0.1:3001", { transports: ["websocket"], reconnection: false });
+const timer = setTimeout(() => {
+    console.error("timeout: no response from Uptime Kuma within 30s");
+    process.exit(1);
+}, 30000);
+
+let finished = false;
+function done(code, msg) {
+    if (finished) return;
+    finished = true;
+    clearTimeout(timer);
+    (code === 0 ? console.log : console.error)(msg);
+    socket.close();
+    process.exit(code);
+}
+
+socket.on("connect_error", (err) => done(1, `connect_error: ${err.message}`));
+socket.on("disconnect", (reason) => done(1, `disconnected before setup finished: ${reason}`));
+
+// Kuma registers socket handlers only after emitting info.
+socket.once("info", () => {
+    socket.emit("needSetup", (needSetup) => {
+        if (!needSetup) {
+            done(0, "already set up");
+            return;
+        }
+        socket.emit("setup", username, password, (res) => {
+            if (res && res.ok) {
+                done(0, "admin user created");
+            } else {
+                done(1, `setup failed: ${res && res.msg ? res.msg : JSON.stringify(res)}`);
+            }
+        });
+    });
+});
@@ -0,0 +1,103 @@
+---
+# Admin bootstrap runs with the Traefik route disabled so /setup is never
+# reachable from outside; the route is enabled once the admin exists.
+
+- name: Read admin credentials from OpenBao
+  community.hashi_vault.vault_kv2_get:
+    url: "{{ uptime_kuma_openbao_url }}"
+    engine_mount_point: "{{ uptime_kuma_openbao_mount }}"
+    path: "{{ uptime_kuma_openbao_path }}"
+    auth_method: token
+  delegate_to: localhost
+  become: false
+  run_once: true
+  register: _uptime_kuma_secret
+  no_log: true
+
+- name: Ensure Uptime Kuma directories exist
+  ansible.builtin.file:
+    path: "{{ item }}"
+    state: directory
+    mode: "0755"
+  loop:
+    - "{{ uptime_kuma_dir }}"
+    - "{{ uptime_kuma_dir }}/data"
+
+- name: Deploy kuma-setup.js
+  ansible.builtin.copy:
+    src: kuma-setup.js
+    dest: "{{ uptime_kuma_dir }}/kuma-setup.js"
+    mode: "0644"
+
+- name: Check for setup marker
+  ansible.builtin.stat:
+    path: "{{ uptime_kuma_dir }}/data/.setup-done"
+  register: _uptime_kuma_marker
+
+- name: Deploy docker-compose.yml
+  ansible.builtin.template:
+    src: docker-compose.yml.j2
+    dest: "{{ uptime_kuma_dir }}/docker-compose.yml"
+    mode: "0644"
+  vars:
+    uptime_kuma_route_enabled: "{{ _uptime_kuma_marker.stat.exists }}"
+
+- name: Pull Uptime Kuma image
+  ansible.builtin.command: docker compose pull
+  args:
+    chdir: "{{ uptime_kuma_dir }}"
+  changed_when: false
+
+- name: Start Uptime Kuma
+  ansible.builtin.command: docker compose up -d
+  args:
+    chdir: "{{ uptime_kuma_dir }}"
+  changed_when: false
+
+- name: Wait for Uptime Kuma on loopback
+  ansible.builtin.uri:
+    url: http://127.0.0.1:3001
+    status_code: 200
+  register: _uptime_kuma_up
+  until: _uptime_kuma_up.status == 200
+  retries: 30
+  delay: 5
+
+- name: Create the admin user if Uptime Kuma is not set up
+  ansible.builtin.command: docker compose exec -T -e KUMA_SETUP_USERNAME -e KUMA_SETUP_PASSWORD uptime-kuma node /app/kuma-setup.js
+  args:
+    chdir: "{{ uptime_kuma_dir }}"
+  environment:
+    KUMA_SETUP_USERNAME: "{{ _uptime_kuma_secret.secret.username }}"
+    KUMA_SETUP_PASSWORD: "{{ _uptime_kuma_secret.secret.password }}"
+  register: _uptime_kuma_setup
+  changed_when: "'admin user created' in _uptime_kuma_setup.stdout"
+  failed_when: false
+  no_log: true
+
+- name: Fail if Uptime Kuma setup failed
+  ansible.builtin.fail:
+    msg: "kuma-setup.js failed: rc={{ _uptime_kuma_setup.rc | default('undefined') }} stdout={{ _uptime_kuma_setup.stdout | default('') }} stderr={{ _uptime_kuma_setup.stderr | default('') }}"
+  when: (_uptime_kuma_setup.rc | default(1)) != 0
+
+- name: Record setup completion
+  ansible.builtin.copy:
+    content: ""
+    dest: "{{ uptime_kuma_dir }}/data/.setup-done"
+    mode: "0644"
+    force: false
+
+- name: Deploy docker-compose.yml with the route enabled
+  ansible.builtin.template:
+    src: docker-compose.yml.j2
+    dest: "{{ uptime_kuma_dir }}/docker-compose.yml"
+    mode: "0644"
+  vars:
+    uptime_kuma_route_enabled: true
+
+- name: Start Uptime Kuma with the route enabled
+  ansible.builtin.command: docker compose up -d
+  args:
+    chdir: "{{ uptime_kuma_dir }}"
+  register: _uptime_kuma_route
+  changed_when: "'Recreate' in _uptime_kuma_route.stderr or 'Started' in _uptime_kuma_route.stderr"
@@ -0,0 +1,38 @@
+services:
+  uptime-kuma:
+    image: louislam/uptime-kuma:{{ uptime_kuma_version }}-slim
+    container_name: uptime-kuma
+    restart: unless-stopped
+    environment:
+      - UPTIME_KUMA_DB_TYPE=sqlite
+    ports:
+      - "127.0.0.1:3001:3001"
+    volumes:
+      - {{ uptime_kuma_dir }}/data:/app/data
+      - {{ uptime_kuma_dir }}/kuma-setup.js:/app/kuma-setup.js:ro
+    labels:
+      - "traefik.enable={{ uptime_kuma_route_enabled | lower }}"
+      - "traefik.http.routers.uptime-kuma.rule=Host(`{{ uptime_kuma_host }}`)"
+      - "traefik.http.routers.uptime-kuma.entrypoints=websecure"
+      - "traefik.http.routers.uptime-kuma.tls=true"
+      - "traefik.http.routers.uptime-kuma.tls.certresolver=letsencrypt"
+      - "traefik.http.routers.uptime-kuma.service=uptime-kuma"
+      - "traefik.http.services.uptime-kuma.loadbalancer.server.port=3001"
+      - "traefik.docker.network={{ uptime_kuma_traefik_network }}"
+    networks:
+      kuma:
+        gw_priority: 100
+      traefik:
+        gw_priority: 0
+    logging:
+      driver: "json-file"
+      options:
+        max-size: "50m"
+        max-file: "2"
+
+networks:
+  kuma:
+    enable_ipv6: true
+  traefik:
+    external: true
+    name: {{ uptime_kuma_traefik_network }}
@@ -18,6 +18,7 @@ RUN apk add --no-cache \
      sshpass

 RUN pip3 install --break-system-packages --no-cache-dir \
+      hvac \
      proxmoxer \
      requests

@@ -0,0 +1,130 @@
+# homelab → konairius/homelab, master → main — Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Move the Gitea repo `k.renner/homelab` into the `konairius` org and rename its default branch `master` → `main`, with no lost Flux sync, pipeline, cron, secret or review.
+
+**Architecture:** Two separate cut-overs, each with its own window, prep PR and rollback: **Cut-over 1** moves the repo (path changes, branch stays `master`); **Cut-over 2** renames the branch (path stays). Everything that can land beforehand lands beforehand; each cut-over's own PR is merged inside its window. The pattern is the one proven on vsftpd, notes, renovate-config, authentik-samba-bridge and homeassistant on 2026-10-18.
+
+**Tech Stack:** Gitea 1.27 (API, transfer, `repoRenameBranch`), Woodpecker v3.19.0 (move API, crons, org secrets), Flux (GitRepository `flux-system`, ImageUpdateAutomation `homelab`), secret-rotator, OpenBao.
+
+**Spec:** this conversation's decisions, recorded in the wiki raw notes of 2026-10-18 (konairius migration series). No separate spec doc.
+
+## Global Constraints
+
+- All repos live in `konairius` (exception: `k.renner/turm1388` stays).
+- The default branch of every repo is `main`.
+- Gitea old paths redirect (301) for reads; **Gitea API writes through an old path fail** (wiki on `k.renner/notes`, 2026-10-18). Every writer must address the new path right after the transfer.
+- A transferred repo keeps Woodpecker's old org link until `POST /api/repos/{id}/move?to=<owner>/<repo>` (homelab: Woodpecker repo id `1`). Org secrets follow the org link.
+- Gitea's `RenameBranch` renames, in one transaction: the branch, the default branch, a protection rule named exactly `master`, and the base/head of unmerged PRs (`models/git/branch.go`). It does **not** keep a `master` ref; anything fetching `master` fails afterwards.
+- Renaming the default branch needs repo admin (owner or site admin), not `claude-bot`.
+- Gitea's transfer removes collaborators who are **members** of the new org (their access then comes only from their konairius team) and keeps non-members (`services/repository/transfer.go`).
+- `woodpecker repo repair` copies the forge's default branch into Woodpecker (`repairRepo` → `Repo.Update` sets `Branch`).
+- Checked live 2026-10-18: Woodpecker repo id `1`; cron ids `alert-monitor` 4, `ci-claude-refresh` 7, `daily-security-scan` 2, `issue-fix` 5, `update-audit` 3, `weekly-update` 1, `wiki-maintenance` 8; the `k.renner` org holds only `claude_code_oauth_token` and `review_bot_token`, every other pipeline secret is a repo secret of homelab.
+- Gitea API: `PATCH /repos/{owner}/{repo}/branches/{branch}` with `{"name": "<new>"}` (`repoRenameBranch`), present on our Gitea.
+- Each service reads only its own OpenBao path; no cross-service key sharing.
+- Never force-push; PRs for every repo change; never `2>/dev/null`.
+
+## Review Focus
+
+1. **Flux fetch across the transfer.** Flux's GitRepository fetches `k.renner/homelab.git` until the URL change lands. Documented behaviour says this works: source-controller v1.9.5 uses go-git v5.19.1 (its `go.mod`), whose `RedirectPolicy` "mirror[s] Git's http.followRedirects config" with the zero value `initial` (pkg.go.dev); git documents `initial` as following the redirect on the first request and using "the redirected URL as the base for the follow-up requests" (`git-config`, `http.followRedirects`). Gitea's 301 stays on the same host and scheme, so fetch and the IUA push both reach `konairius/homelab`. Fallback only, should that fail: Task 3 has a declared break-glass (suspend the `flux-system` Kustomization so it cannot re-apply the old URL, patch the GitRepository URL to the value the PR sets, resume once the source is Ready on the merge commit), checked by `flux get source git flux-system`.
+6. **Write access lost in the transfer.** Any writer that is a konairius org member loses its collaborator grant and keeps only its team permission (`flux` pushes for image automation; claude-bot, issue-fix-bot, security-bot, review-bot, argus-bot, renovate-bot write PRs/reviews). Expect: Task 3 Step 0 snapshot of collaborators, konairius teams and the branch-protection whitelists, compared after Step 1.
+2. **Image automation push between merge and rename (Cut-over 2).** The IUA pushes to `master`; after the Task 5 PR it expects `main`. Expect: IUA suspended for the whole window and resumed only after Flux reports `main`.
+3. **Org secrets after the Woodpecker move.** Homelab pipelines use the org secrets `claude_code_oauth_token` and `review_bot_token`; after the move they resolve in `konairius`. Expect: both exist in `konairius` before Cut-over 1 (Task 1 verification).
+4. **Crons on a vanished branch.** All 7 crons run on `master`. Expect: each switched to `main` in place (`woodpecker repo cron update --branch main`) inside the Cut-over 2 window, verified by `cron ls`.
+5. **Rotations that verify against the old path.** flux-git (`GITEA_REQUIRE_PUSH=true`, verify repo `k.renner/homelab`) would fail every quarter. Expect: verify repo switched in Task 2 and a manual rotator run in Task 3.
+
+---
+
+### Task 1: Org secrets in konairius before the move
+
+**Files:**
+- Modify: `kubernetes/infrastructure/openbao/rotation/claude-oauth.yaml` (add a second container `sync-woodpecker-konairius`, same env with `WOODPECKER_ORG=konairius`)
+- Modify: `kubernetes/infrastructure/openbao/rotation/review-bot.yaml` (same: a second sync container for `konairius`, `WOODPECKER_SECRET_NAME=review_bot_token`, events `cron,manual,pull_request`)
+
+**Interfaces:** Produces the konairius org secrets `claude_code_oauth_token` and `review_bot_token` that Task 3 relies on. The k.renner containers stay until Task 4.
+
+- [ ] **Step 1:** Add the containers. Both CronJobs reuse their existing OpenBao role (it only reads OpenBao and the woodpecker-bot bootstrap; no policy change).
+- [ ] **Step 2:** `kubectl kustomize kubernetes/infrastructure/openbao/rotation` renders.
+- [ ] **Step 3:** PR, merge, `flux reconcile kustomization infrastructure`.
+- [ ] **Step 4:** Run both once: `kubectl create job -n openbao --from=cronjob/claude-oauth-secret-sync claude-oauth-konairius` and `--from=cronjob/review-bot-secret-rotate review-bot-konairius`. Expected logs: `updated|created woodpecker org secret konairius/<name>`. Note: the review-bot run also executes its init containers `rotate-mint` and `rotate-mint-mcp`, i.e. mints and reaps **both** review-bot PATs off schedule. Keeping the two newest makes one extra run safe; afterwards check `kubectl get externalsecret -n review-bot review-bot-secrets` is SecretSynced before anything else rotates.
+- [ ] **Step 5:** `woodpecker org secret ls --organization konairius` lists `claude_code_oauth_token`, `review_bot_token`, `registry_bot_token`; `woodpecker org secret ls --organization k.renner` still lists only `claude_code_oauth_token` and `review_bot_token` (nothing else to carry over).
+
+### Task 2: PR "follow homelab to konairius/homelab" (prepared, merged in Task 3)
+
+**Files (all FUNCTIONAL `k.renner/homelab` references, 2026-10-18 inventory):**
+- `kubernetes/clusters/homelab/flux-system/gotk-sync.yaml:14` — GitRepository url → `https://gitea.renner.uno/konairius/homelab.git`
+- `kubernetes/infrastructure/openbao/rotation/flux-git.yaml:81` — `GITEA_VERIFY_REPO` → `konairius/homelab` (and the comment at :84)
+- `kubernetes/apps/review-bot/deployment.yaml:38` — `REPOS` entry → `konairius/homelab`
+- `.woodpecker/alert-monitor.yml:133,241`, `ci-claude-refresh.yml:177,179,200`, `issue-fix.yml:85,166,190,199`, `pr-review.yml:46`, `security-scan.yml:150,160`, `update-audit.yml:114` — API, clone and push URLs
+- Header comments with `--repo k.renner/homelab` / `pipeline deploy k.renner/homelab` in the same files and `e2e.yml:10`
+- `review-bot/go.mod:1` → `module gitea.renner.uno/konairius/homelab/review-bot` (no Go file imports it) and the test fixtures in `review-bot/*_test.go` (consistency only)
+- `ci/images/heating-can/Containerfile:66` — OCI source label
+
+- [ ] **Step 1:** Apply the replacements; leave `docs/`, `PROPOSAL*` and `MIGRATION*` history as is.
+- [ ] **Step 2:** `git grep -n 'k.renner/homelab' -- ':!docs'` returns only historical files (`PROPOSAL*`, `MIGRATION*`).
+- [ ] **Step 3:** `go test -C review-bot ./...` passes; `kubectl kustomize kubernetes/clusters/homelab` and the touched app directories render.
+- [ ] **Step 4:** Open the PR titled "(merge inside Cut-over 1 only)"; do not merge.
+
+### Task 3: Cut-over 1 — transfer (window)
+
+**Preconditions:** Task 1 verified; Task 2 PR green; no deploy pipeline running (`woodpecker pipeline ls k.renner/homelab --limit 5`); record `flux get source git flux-system` revision.
+
+- [ ] **Step 0 (owner, needs admin):** snapshot `tea api --login renner.uno /repos/k.renner/homelab/collaborators`, `tea api --login renner.uno /orgs/konairius/teams` plus each team's members, and the `master` rule's push/merge/approvals whitelists (`tea api --login renner.uno /repos/k.renner/homelab/branch_protections`). Any writer that is a konairius member must get write access through its team, or be re-added as collaborator right after Step 1.
+- [ ] **Step 1 (owner):** `tea api --login renner.uno -X POST /repos/k.renner/homelab/transfer -f new_owner=konairius`. Expect `curl -sI https://gitea.renner.uno/k.renner/homelab` → 301.
+- [ ] **Step 2 (claude-bot):** Woodpecker move: `POST $WOODPECKER_SERVER/api/repos/1/move?to=konairius/homelab` → 204; `woodpecker repo ls` shows `konairius/homelab`.
+- [ ] **Step 3 (owner):** merge the Task 2 PR.
+- [ ] **Step 1a:** repeat the Step 0 reads against `konairius/homelab` and compare; re-add any lost writer as collaborator before continuing.
+- [ ] **Step 4:** `flux reconcile source git flux-system`. If it fails to fetch: break-glass — `flux suspend kustomization flux-system` (else it re-applies the last good artifact with the old URL), then `kubectl -n flux-system patch gitrepository flux-system --type merge -p '{"spec":{"url":"https://gitea.renner.uno/konairius/homelab.git"}}'` (the value the PR sets), wait for the source to be Ready on the Task 2 merge commit, then `flux resume kustomization flux-system`. Expect: revision = Task 2 merge commit, Ready.
+- [ ] **Step 5:** `flux reconcile image update homelab` after the next ImagePolicy change, or check the last IUA push reaches `konairius/homelab` (commit by Flux Image Automation on master).
+- [ ] **Step 6:** Run flux-git rotator once (`kubectl create job -n openbao --from=cronjob/flux-git-secret-rotate flux-git-move`); log shows `pull+push verified` against `konairius/homelab`.
+- [ ] **Step 6a:** Expected side effects of the Task 2 merge, not failures: `build-ci-images` rebuilds the review-bot image (go.mod, tests) and heating-can (label), and image automation rolls out the new review-bot tag; `ci-claude-refresh` runs (its own file is in its path filter) and may open a ci-claude bump PR.
+- [ ] **Step 7:** Verify writers: a PR on konairius/homelab gets a review-bot review; `woodpecker pipeline ls konairius/homelab` shows the merge's push pipeline green; an agent cron (alert-monitor, every 15 min) succeeds; `security-scan`/`issue-fix` open PRs against the new path at their next run.
+- [ ] **Step 8:** Check the GitHub push mirror (`konairius/Homelab` on GitHub, restore-test source) still syncs (Gitea repo Settings → Mirror, last sync after the transfer).
+
+**Rollback:** owner transfers back to `k.renner`, Woodpecker move back to `k.renner/homelab`, revert the Task 2 PR.
+
+### Task 4: After Cut-over 1
+
+- [ ] Remove the `k.renner` sync containers from Task 1 (nothing in the `k.renner` Woodpecker org uses them any more; turm1388 uses repo secrets only). PR, reconcile.
+- [ ] Workstation: homelab clone remote → `https://gitea.renner.uno/konairius/homelab.git`; `~/source/CLAUDE.md:13` row → `konairius/homelab`.
+- [ ] Wiki deposit of the observed Cut-over 1 results.
+
+### Task 5: PR "default branch main" (prepared, merged in Task 6)
+
+**Files (all FUNCTIONAL `master` references):**
+- `.woodpecker/build-ci-images.yml:39`, `ci-claude-refresh.yml:71`, `deploy-claude-workstation.yml:4`, `deploy-edge-mqtt-bridge.yml:4`, `deploy-infrastructure.yml:7`, `deploy-netbird-client.yml:4`, `deploy-netbird-proxy.yml:4`, `deploy-netbird-server.yml:4`, `security-scan.yml:72` — `branch: main`
+- `.woodpecker/ci-claude-refresh.yml:211`, `issue-fix.yml:202`, `security-scan.yml:155` — PR `base: "main"`
+- `kubernetes/clusters/homelab/flux-system/gotk-sync.yaml:11` — `ref.branch: main`
+- `kubernetes/infrastructure/image-automation/update-automation.yaml:26,36` — checkout and push branch `main`
+- `kubernetes/restore-test/flux-root.yaml:16`, `kubernetes/vmtest-job.yaml:90` — `main`
+- `kubernetes/bootstrap.sh:107` default `main`, `:1478-1479` guard on `main`, `:102` example
+- **Not** the prompts: `review-bot/prompt.md` is baked into the review-bot image, which `build-ci-images` only rebuilds on a push to the branch its `when:` names. In this PR that filter flips to `main` while the PR merges into `master`, so the prompt edit would not ship. It moves to Task 6 Step 9.
+
+- [ ] **Step 1:** Apply; `git grep -n -w master -- ':!docs' ':!ansible'` returns only historical/runbook text (handled in Task 7), the two prompts, and unrelated words (VRRP, Open3E, Multus `"master"`).
+- [ ] **Step 2:** `bash -n kubernetes/bootstrap.sh`; `kubectl kustomize kubernetes/clusters/homelab` renders.
+- [ ] **Step 3:** Open the PR titled "(merge inside Cut-over 2 only)"; do not merge.
+
+### Task 6: Cut-over 2 — rename master → main (window)
+
+**Preconditions:** Cut-over 1 done; Task 5 PR green; no deploy pipeline running.
+
+- [ ] **Step 1:** `flux suspend image update homelab`.
+- [ ] **Step 2 (owner):** merge the Task 5 PR into `master`. Flux now points at `main`, which does not exist yet; the cluster keeps its last applied state.
+- [ ] **Step 3 (owner, immediately):** `tea api --login renner.uno -X PATCH /repos/konairius/homelab/branches/master -f name=main`. Expect: default branch `main`, protection rule now named `main` (`GET /repos/konairius/homelab/branches/main` → `protected: true, required_approvals: 1`), open PRs based on `main`.
+- [ ] **Step 4:** `flux reconcile source git flux-system` → Ready on `main@<merge commit>`; `flux get kustomizations` all Ready.
+- [ ] **Step 5:** Crons: for each of `alert-monitor`(4), `ci-claude-refresh`(7), `daily-security-scan`(2), `issue-fix`(5), `update-audit`(3), `weekly-update`(1): `woodpecker repo cron update --repository konairius/homelab --id <id> --branch main`. Delete `wiki-maintenance`(8): no pipeline filters on it (`git grep wiki-maintenance -- .woodpecker` is empty), it starts nothing. `cron ls` shows six crons, all on `main`.
+- [ ] **Step 6:** `woodpecker repo repair konairius/homelab`; `woodpecker repo show` shows branch `main`.
+- [ ] **Step 7:** `flux resume image update homelab`; next IUA commit lands on `main`.
+- [ ] **Step 8:** Verify: a small PR into `main` gets reviewed and its merge triggers the push pipelines; the deploy pipelines' `when: branch: main` fire.
+- [ ] **Step 9:** PR into `main` updating `review-bot/prompt.md:16` and `ci/agents/pr-review/mistral-prompt.md:16` (all repos use `main`). Its merge is a push to `main` touching `review-bot/**`, so `build-ci-images` rebuilds the review-bot image; image automation rolls it out; review-bot's log shows the Mistral agents re-synced (new prompt hash). This PR doubles as the Step 8 test PR.
+- [ ] **Step 10 (owner, GitHub):** the push mirror `konairius/Homelab` on GitHub now carries `main`. GitHub refuses to delete a repo's default branch, so first set its default branch to `main` (repo Settings → Branches), then delete `master` there. `kubernetes/restore-test/flux-root.yaml` already points at `main` (Task 5).
+
+**Rollback:** `PATCH .../branches/main -f name=master`, revert the Task 5 PR, crons back to `master` (re-add `wiki-maintenance` only if wanted), resume IUA.
+
+### Task 7: Doc and memory sweep
+
+- [ ] One PR replacing remaining `k.renner/homelab` and `master` in runbooks and READMEs: `kubernetes/RUNBOOK-cold-rebuild.md` (incl. `flux bootstrap --branch=master` at :282), `RUNBOOK-home-assistant-image-rollback.md`, `kubernetes/infrastructure/image-automation/README.md`, `README.md`, pipeline comments, `ci/agents/pr-review/run.sh`. Leave dated plans/specs and `MIGRATION*` history unchanged.
+- [ ] Update the two memory notes that assume `master` (`feedback_image_bumps_via_flux_automation.md`, vican `verify-repo-freshness-before-review.md`).
+- [ ] Local clones: `git branch -m master main && git fetch origin && git branch -u origin/main main` (owner's workstation).
+- [ ] Wiki deposit of Cut-over 2 results.
@@ -0,0 +1,250 @@
+# kuma-sync Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Replace AutoKuma with an in-house Go controller that reconciles typed `KumaMonitor` resources into Uptime Kuma 2.5.6, with ownership stored as a Kuma tag.
+
+**Architecture:** A controller-runtime manager watches `KumaMonitor` (cluster-wide) and talks to Kuma through `breml/go-uptime-kuma-client` wrapped behind an internal `kumaclient.Client` interface. Each resource maps to one Kuma monitor, found by the tag `kuma-sync=<namespace>/<name>`. Finalizers and a periodic garbage collection keep Kuma free of orphans. The controller has no local state.
+
+**Tech Stack:** Go 1.27, controller-runtime v0.25.2, controller-gen (CRD + deepcopy), `github.com/breml/go-uptime-kuma-client` v0.6.2, envtest, testcontainers-go, kaniko (Woodpecker), Flux (Kustomization + image automation), ESO/OpenBao, Cilium.
+
+**Spec:** `docs/superpowers/specs/2026-10-18-kuma-sync-design.md`
+
+## Global Constraints
+
+- **Latest stable versions everywhere** (owner requirement). As of 2026-10-18 that is:
+  - Go 1.27 (`go` directive and builder image)
+  - controller-runtime v0.25.2, with the k8s.io libraries and controller-gen/envtest versions it requires
+  - go-uptime-kuma-client v0.6.2
+  - Uptime Kuma 2.5.6 (latest stable; 3.0 is nightly only)
+  - the latest testcontainers-go
+
+  Each task that adds a dependency first checks its latest release (GitHub releases / `go list -m -versions`) and uses that. Before the final commit of each task, run `go list -m -u all` and record that it reports no available updates for direct dependencies. If Kuma ships a newer stable release before Task 7, bump the VPS role and the test image together.
+- Module path `gitea.renner.uno/k.renner/homelab/kuma-sync`, source in `ci/images/kuma-sync/`.
+- Kuma client: `github.com/breml/go-uptime-kuma-client v0.6.2`, exact version. Copy its `replace github.com/maldikhan/go.socket.io => github.com/breml/go.socket.io <same pseudo-version>` from that release's `go.mod`.
+- Kuma under test: `louislam/uptime-kuma:2.5.6-slim`. That is the same image the VPS runs (`ansible/roles/uptime-kuma/defaults/main.yml`).
+- CRD: group `uptime.renner.uno`, version `v1alpha1`, kind `KumaMonitor`, plural `kumamonitors`, namespaced.
+- Ownership tag: Kuma tag name `kuma-sync`; value `<namespace>/<name>`. Never read, edit or delete a monitor without that tag.
+- Finalizer name: `uptime.renner.uno/kuma-sync`.
+- Requeue when a parent group does not exist yet: 10 s. Full resync and orphan GC: every 5 min.
+- Kuma URL `https://kuma.renner.uno`; credentials from OpenBao KV v2 mount `homelab`, path `infrastructure/uptime-kuma`, keys `username`, `password` (reuse the existing secret; this controller is Kuma's only API client).
+- Image `gitea.renner.uno/gitea_admin/kuma-sync`, tag `YYYY-MM-DD-HHMM`, Flux ImagePolicy picks the newest (pattern of `kubernetes/infrastructure/image-automation/authentik-gate-sync.yaml`).
+- Unit tests run as a stage of the image build (house pattern for authentik-gate-sync). Integration tests (build tag `integration`) need Docker and run locally, not in CI.
+- No `2>/dev/null`. Config comments are terse factual lines. Commits as claude-bot. Every change goes through a PR. No force-push.
+
+## Review Focus
+
+1. **Restart or rebuild duplicates monitors.** That was the AutoKuma failure mode. The adopt-by-tag path is pinned by integration test `TestRestartAdoptsByTag` (Task 3) and reconciler unit test `TestReconcileAdoptsExisting` (Task 4).
+2. **Deletion while the controller is down orphans a monitor.** The GC pass is pinned by `TestGCDeletesOrphans` (Task 5) and integration `TestDeleteWhileDownIsCollected` (Task 6).
+3. **A hand-made Kuma monitor gets touched.** `TestGCIgnoresUntagged` (Task 5) and integration `TestUntaggedMonitorUntouched` (Task 6).
+4. **`editMonitor` is a full overwrite.** Sending a partial object silently clears fields such as `parent` or `accepted_statuscodes`. Pinned by integration `TestUpdateKeepsUnchangedFields` (Task 3).
+5. **Children are created before their group.** They must requeue after 10 s, not fail for minutes. Pinned by `TestReconcileWaitsForParent` (Task 4).
+
+---
+
+### Task 1: Module, API types, generated CRD
+
+**Files:**
+- Create: `ci/images/kuma-sync/go.mod`, `go.sum`
+- Create: `ci/images/kuma-sync/api/v1alpha1/kumamonitor_types.go`, `groupversion_info.go`, generated `zz_generated.deepcopy.go`
+- Create: `ci/images/kuma-sync/config/crd/uptime.renner.uno_kumamonitors.yaml` (generated)
+- Create: `ci/images/kuma-sync/Makefile` with targets `generate` (controller-gen object + crd), `test`, `test-integration`
+- Test: `ci/images/kuma-sync/api/v1alpha1/validation_test.go` (envtest)
+
+**Interfaces:**
+- Produces the type `KumaMonitorSpec`:
+  - `Type` enum: `group|http|keyword|json-query|dns|port|push`.
+  - `DisplayName string` (required).
+  - `ParentRef *LocalRef{Name}`.
+  - `Interval`, `RetryInterval` (`int32` seconds, min 20, defaults 60).
+  - `MaxRetries` (`int32`, default 0).
+  - `Timeout` (`int32` seconds, min 1).
+  - `Paused bool`.
+  - `Description string`.
+  - `HTTP *HTTPSpec` holds `URL` (required), `Method` (default GET), `AcceptedStatusCodes []string` (default `["200-299"]`), `Headers map[string]string`, `Body string`, `MaxRedirects *int32`, `IgnoreTLS bool`, `ExpiryNotification bool`. It is used by `http`, `keyword` and `json-query`.
+  - `Keyword *KeywordSpec{Keyword, Invert bool}`.
+  - `JSONQuery *JSONQuerySpec`: `Expression string` (JSONata), `Operator` enum `==|!=|<|<=|>|>=|contains`, `Expected string`.
+  - `DNS *DNSSpec{Hostname, ResolveType enum A|AAAA|CNAME|MX|NS|PTR|SOA|SRV|TXT|CAA, ResolveServer default "1.1.1.1", Port default 53}`.
+  - `Port *PortSpec{Hostname, Port int32 1-65535}`.
+  - `Push *PushSpec{}`, an empty marker.
+- Produces the type `KumaMonitorStatus{MonitorID int64, ObservedGeneration int64, Conditions []metav1.Condition}`, where `Ready` is the only condition type.
+- CEL rules on the spec:
+  - `type in ['http','keyword','json-query'] == has(self.http)`
+  - `(type == 'keyword') == has(self.keyword)`
+  - `(type == 'json-query') == has(self.jsonQuery)`
+  - `(type == 'dns') == has(self.dns)`
+  - `(type == 'port') == has(self.port)`
+  - `(type == 'push') == has(self.push)`
+  - `type == 'group'` implies none of the blocks are set.
+
+- [ ] **Step 1: Write failing envtest validation tests.** Each test applies a `KumaMonitor` and asserts the API server's answer:
+  - `TestValidKeyword`: type keyword with http+keyword is accepted.
+  - `TestKeywordWithoutBlock`: rejected; the error contains `keyword`.
+  - `TestGroupWithHTTP`: rejected.
+  - `TestJSONQueryBadOperator`: operator `=~` is rejected.
+  - `TestIntervalBelowMin`: interval 5 is rejected.
+  - `TestDefaults`: an applied http monitor reads back `interval 60` and `acceptedStatusCodes ["200-299"]`.
+- [ ] **Step 2: Run** `make test`. Expected: FAIL, because the types are missing.
+- [ ] **Step 3: Write the types with kubebuilder markers, then run** `make generate`.
+- [ ] **Step 4: Run** `make test`. Expected: all 6 PASS.
+- [ ] **Step 5: Commit** `feat(kuma-sync): KumaMonitor API types and CRD`.
+
+### Task 2: Kuma client interface and fake
+
+**Files:**
+- Create: `ci/images/kuma-sync/internal/kumaclient/client.go` (interface + domain types)
+- Create: `ci/images/kuma-sync/internal/kumaclient/fake.go` (in-memory fake used by reconciler tests)
+- Test: `ci/images/kuma-sync/internal/kumaclient/fake_test.go`
+
+**Interfaces:**
+- Produces:
+  ```go
+  type Monitor struct { ID int64; Type, Name, Description string; Parent *int64; Active bool
+      Interval, RetryInterval, MaxRetries, Timeout int32
+      URL, Method, Body string; Headers map[string]string; AcceptedStatusCodes []string; MaxRedirects int32; IgnoreTLS, ExpiryNotification bool
+      Keyword string; InvertKeyword bool; JSONPath, JSONPathOperator, ExpectedValue string
+      Hostname string; Port int32; DNSResolveType, DNSResolveServer string
+      OwnerKey string } // value of the kuma-sync tag; "" = not ours
+  type Client interface {
+      ListOwned(ctx) ([]Monitor, error)            // only monitors carrying the kuma-sync tag
+      Create(ctx, m Monitor) (int64, error)        // creates and tags with m.OwnerKey
+      Update(ctx, m Monitor) error                 // full overwrite of an owned monitor; errors if not owned
+      Delete(ctx, id int64) error                  // errors if not owned
+  }
+  ```
+- The fake also holds untagged monitors (`AddForeign(Monitor)`), so the "never touch untagged" rule can be tested.
+
+- [ ] **Step 1: Write failing tests:**
+  - `TestFakeListOwnedHidesForeign`
+  - `TestFakeUpdateRejectsForeign`
+  - `TestFakeDeleteRejectsForeign`
+  - `TestFakeCreateAssignsIDAndTag`
+- [ ] **Step 2: Run** `go test ./internal/kumaclient/...`. Expected: FAIL.
+- [ ] **Step 3: Implement the interface and the fake.**
+- [ ] **Step 4: Run** the tests. Expected: PASS.
+- [ ] **Step 5: Commit** `feat(kuma-sync): Kuma client interface and fake`.
+
+### Task 3: Real client on breml/go-uptime-kuma-client + integration tests
+
+**Files:**
+- Create: `ci/images/kuma-sync/internal/kumaclient/breml.go`
+- Test: `ci/images/kuma-sync/internal/kumaclient/breml_integration_test.go` (`//go:build integration`)
+
+**Interfaces:**
+- Consumes the `Client` interface and `Monitor` from Task 2.
+- Produces `NewBreml(ctx, url, username, password string) (Client, error)`. It logs in once and reuses the session (Kuma rate-limits logins). It ensures the tag `kuma-sync` exists, creating it on first use with color `#2563eb`.
+
+Integration harness: testcontainers-go starts `louislam/uptime-kuma:2.5.6-slim` with `UPTIME_KUMA_DB_TYPE=sqlite` and waits for port 3001. Setup must then create the admin. Use the client's setup call if it has one; otherwise emit `needSetup`/`setup` after the `info` event, exactly as `ansible/roles/uptime-kuma/files/kuma-setup.js` does.
+
+- [ ] **Step 1: Write failing integration tests:**
+  - `TestCreateFieldsIntact`: creates a keyword, a json-query (operator `contains`), a dns, a port and a group monitor, then reads them back through a fresh client. Every field from Task 2's `Monitor` must equal the input.
+  - `TestUpdateKeepsUnchangedFields`: updates only `Interval` from 60 to 120. On re-read, `Parent`, `AcceptedStatusCodes`, `Keyword` and `ExpiryNotification` are unchanged.
+  - `TestRestartAdoptsByTag`: creates monitors, discards the client, builds a new one. `ListOwned` returns the same IDs with the same `OwnerKey`s.
+  - `TestUntaggedMonitorUntouched`: a monitor created through the raw library without a tag is absent from `ListOwned`, and `Update`/`Delete` on its ID return an error.
+- [ ] **Step 2: Run** `go test -tags integration ./internal/kumaclient/...`. Expected: FAIL.
+- [ ] **Step 3: Implement `breml.go`.** Map `Monitor` to the library's per-type monitor structs. Tag with `AddMonitorTag(tagID, monitorID, ownerKey)`. For `Update`, read the current full object and overwrite only the fields we manage, as Review Focus 4 requires.
+- [ ] **Step 4: Run** the integration tests. Expected: all 4 PASS.
+- [ ] **Step 5: Commit** `feat(kuma-sync): Kuma client on go-uptime-kuma-client`.
+
+### Task 4: Reconciler
+
+**Files:**
+- Create: `ci/images/kuma-sync/internal/controller/kumamonitor_controller.go`
+- Create: `ci/images/kuma-sync/internal/controller/mapping.go` (spec → `kumaclient.Monitor`)
+- Test: `ci/images/kuma-sync/internal/controller/kumamonitor_controller_test.go` (controller-runtime fake client + Kuma fake)
+- Test: `ci/images/kuma-sync/internal/controller/mapping_test.go`
+
+**Interfaces:**
+- Consumes `kumaclient.Client` and the API types.
+- Produces `Reconciler{Client client.Client; Kuma kumaclient.Client}` with `Reconcile(ctx, req) (ctrl.Result, error)` and `SetupWithManager(mgr)`.
+- Algorithm:
+  1. Get the resource.
+  2. If it is being deleted, delete the owned monitor by OwnerKey (absent counts as success) and remove the finalizer.
+  3. Ensure the finalizer is present.
+  4. Resolve `parentRef`: the parent `KumaMonitor` must exist and have `status.monitorID`. If not, set `Ready=False` with reason `ParentPending` and requeue after 10 s.
+  5. Map the spec to the desired `Monitor`, with `OwnerKey = ns/name`.
+  6. Find the existing monitor via `ListOwned` by OwnerKey. If there is none, `Create`. If it differs on managed fields, `Update`.
+  7. Set the status: monitorID, observedGeneration, `Ready=True`.
+  8. Requeue after 5 min.
+
+- [ ] **Step 1: Write failing tests:**
+  - `TestMappingAllTypes`: a table test, one row per type, showing that spec fields land on the right `Monitor` fields; `Paused` maps to `Active=false`.
+  - `TestReconcileCreates`
+  - `TestReconcileAdoptsExisting`: the fake already holds a monitor with the same OwnerKey. Expected: no second create, and status.monitorID equals the existing ID.
+  - `TestReconcileUpdatesDrift`: the fake monitor's interval differs. Expected: one `Update`.
+  - `TestReconcileNoopWhenEqual`: zero Update calls.
+  - `TestReconcileWaitsForParent`: a child whose group has no monitorID gets `RequeueAfter == 10s` and `Ready=False/ParentPending`.
+  - `TestReconcileDeleteRemovesMonitorAndFinalizer`
+  - `TestReconcileDeleteToleratesMissingMonitor`
+- [ ] **Step 2: Run** `go test ./internal/controller/...`. Expected: FAIL.
+- [ ] **Step 3: Implement the mapping and the reconciler.**
+- [ ] **Step 4: Run** the tests. Expected: PASS.
+- [ ] **Step 5: Commit** `feat(kuma-sync): KumaMonitor reconciler`.
+
+### Task 5: Orphan garbage collection, manager, image
+
+**Files:**
+- Create: `ci/images/kuma-sync/internal/controller/gc.go` (a `manager.Runnable` ticking every 5 min)
+- Create: `ci/images/kuma-sync/cmd/kuma-sync/main.go`
+- Create: `ci/images/kuma-sync/Containerfile`. Stage 1 is `golang` (pinned digest), runs `go test ./...` without tags, then builds a static binary. Stage 2 is distroless static nonroot.
+- Modify: `.woodpecker/build-ci-images.yml`. Add a `build-kuma-sync` step that mirrors `build-authentik-gate-sync`, with tag `YYYY-MM-DD-HHMM` plus `latest`.
+- Test: `ci/images/kuma-sync/internal/controller/gc_test.go`
+
+**Interfaces:**
+- Produces `GC{Client client.Client; Kuma kumaclient.Client; Interval time.Duration}`. Each run deletes every owned monitor whose OwnerKey has no matching `KumaMonitor`. A list error from either side aborts the run, so nothing is deleted on partial information.
+- `main.go` reads env `KUMA_URL`, `KUMA_USERNAME` and `KUMA_PASSWORD`. Missing env makes it exit non-zero with a message naming the variable. Health probes run on `:8081`, metrics on `:8080`, and there is no leader election.
+
+- [ ] **Step 1: Write failing tests:**
+  - `TestGCDeletesOrphans`
+  - `TestGCIgnoresUntagged`: a foreign monitor in the fake survives.
+  - `TestGCKeepsLiveResources`
+  - `TestGCAbortsOnListError`: the fake k8s list fails, and zero deletes happen.
+- [ ] **Step 2: Run** the tests. Expected: FAIL.
+- [ ] **Step 3: Implement the GC and `main.go`.**
+- [ ] **Step 4: Run** `go test ./...` (expected: PASS), then `docker build -f Containerfile .` in `ci/images/kuma-sync` (expected: the build succeeds, with the test stage passing).
+- [ ] **Step 5: Commit** `feat(kuma-sync): orphan GC, manager and image build`. Open a PR. After the owner merges it, the controller confirms the first image tag exists in the registry before Task 7.
+
+### Task 6: End-to-end integration test (automated pilot)
+
+**Files:**
+- Test: `ci/images/kuma-sync/internal/controller/e2e_integration_test.go` (`//go:build integration`)
+
+The test runs envtest (an API server with the CRD) plus a Kuma 2.5.6 container plus the real manager, with the breml client and GC interval 2 s.
+
+- [ ] **Step 1: Write the tests:**
+  - `TestE2EGroupNesting`: apply group `outer`, group `inner` (parent outer), and a dns monitor (parent inner), all at once. Within 60 s, all three are in Kuma with the right parent IDs.
+  - `TestE2ERestartNoDuplicates`: stop the manager, start a new one, wait 2 GC intervals. The monitor count in Kuma is unchanged.
+  - `TestDeleteWhileDownIsCollected`: stop the manager, remove the finalizer, delete the resource, start the manager. The monitor is gone from Kuma within 2 GC intervals.
+  - `TestE2EDriftRepaired`: change the interval directly in Kuma via the raw library. The next resync restores the spec value.
+- [ ] **Step 2: Run** `go test -tags integration ./internal/controller/...`. Expected: PASS. Any failure is a defect, not something to retry.
+- [ ] **Step 3: Commit** `test(kuma-sync): end-to-end integration suite`.
+
+### Task 7: Kubernetes deployment
+
+**Files:**
+- Create: `kubernetes/apps/kuma-sync/{crd-kumamonitors.yaml (copied from config/crd), rbac.yaml, externalsecret.yaml, deployment.yaml, kustomization.yaml}`
+- Create: `kubernetes/clusters/homelab/kuma-sync.yaml`. It is a Flux Kustomization modeled on the removed `autokuma.yaml`: dependsOn infrastructure and infrastructure-crds, with the CEL ExternalSecret health check.
+- Create: `kubernetes/infrastructure/network-policies/kuma-sync-ns.yaml`, the same shape as the removed `autokuma-ns.yaml`: ingress `[{}]`, DNS with `rules.dns`, kube-apiserver, `toFQDNs kuma.renner.uno:443`. Allow kubelet probes from `host`.
+- Create: `kubernetes/infrastructure/image-automation/kuma-sync.yaml` (ImageRepository + ImagePolicy).
+- Modify: `namespaces.yaml` (add `kuma-sync`), `network-policies/kustomization.yaml`, and the `openbao-clustersecretstore.yaml` allowlist (sorted).
+
+**Interfaces:**
+- Deployment: image `gitea.renner.uno/gitea_admin/kuma-sync:<first tag from Task 5>` with the setter `# {"$imagepolicy": "flux-system:kuma-sync"}`. 1 replica, `Recreate`. Security context as in `kubernetes/apps/uptime-monitor/deployment.yaml`, with a read-only root filesystem.
+- ClusterRole: `kumamonitors` get/list/watch/update/patch, `kumamonitors/status` get/update/patch, `kumamonitors/finalizers` update, and `events` create/patch.
+
+- [ ] **Step 1: Write the manifests.**
+- [ ] **Step 2: Verify:**
+  - `kubectl kustomize` on every touched directory renders.
+  - `kubectl apply --dry-run=server -f kubernetes/apps/kuma-sync/crd-kumamonitors.yaml` succeeds.
+- [ ] **Step 3: Commit** `feat(kuma-sync): deploy controller` and open a PR. After merge, the controller checks:
+  - `flux get kustomization kuma-sync` reports Ready.
+  - The pod is Running.
+  - The Kuma log shows a login from the controller.
+- [ ] **Step 4: Live smoke test** in a follow-up PR: one `KumaMonitor` (keyword on www.renner.uno) in namespace `kuma-sync`. Expected:
+  - It shows up in Kuma, tagged `kuma-sync=kuma-sync/www-renner-uno`.
+  - Deleting the pod changes nothing in Kuma.
+  - Removing it from git deletes the monitor.
+
+## Follow-up (parent plan)
+
+Parent plan `2026-10-18-uptime-kuma.md` Task 3 (pilot) is replaced by Tasks 6 and 7 here. Its Tasks 4 and 5 then use `KumaMonitor` instead of `KumaEntity`.
@@ -0,0 +1,168 @@
+# Uptime Kuma (replace UptimeRobot) Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Replace UptimeRobot with a self-hosted Uptime Kuma on the NetBird VPS, with every monitor, notification and the status page declared in this repo.
+
+**Architecture:** Uptime Kuma runs as an Ansible-managed container on `netbird.renner.uno` behind that host's existing Traefik, and checks targets over the public internet (no NetBird dependency). An in-cluster controller turns `KumaEntity` custom resources into Kuma monitors over Kuma's public HTTPS endpoint. The cluster's blackbox exporter probes Kuma itself, so a dead VPS still raises an alarm. Kuma moves to its own VPS later by retargeting the Ansible play and DNS; nothing else changes.
+
+**Tech Stack:** Uptime Kuma 2.5.6 (`louislam/uptime-kuma:2.5.6-slim`, SQLite), AutoKuma 2.0.0 (`ghcr.io/bigboot/autokuma:2.0.0`, Kubernetes source), Ansible + docker compose, Traefik (docker provider), Flux, ESO/OpenBao, Woodpecker.
+
+**Spec:** this conversation (2026-10-18). There is no separate spec file; the decisions are recorded under *Decisions* below.
+
+## Decisions (from the design conversation)
+
+- Kuma lives **off-site**, on the NetBird coordinator VPS for now. It gets its own VPS once the setup is accepted. The NetBird coordinator is not in the ingress path, so sharing the host does not skew what the probes measure.
+- Monitors are **declared in the repo** as custom resources and reconciled by a controller. A ready-made controller is used if it passes the pilot gate (Task 3). Otherwise we write our own, under a separate plan.
+- Detailed checks (keyword, JSON query, DNS, TCP, certificate expiry) are a goal, not an afterthought. The custom-resource schema must carry them from the first monitor.
+- The UptimeRobot IngressMonitorController (`kubernetes/apps/uptime-monitor/`) is removed after cutover.
+
+## Owner answers (2026-10-18)
+
+1. The credential source is OpenBao. The play reads it with `community.hashi_vault`.
+2. Public DNS is managed in the Cloudflare UI. The owner creates `kuma.renner.uno` before Task 1 deploys and repoints `uptime.renner.uno` in Task 5.
+3. The SMTP sender is `uptime@renner.uno`. Its Proton SMTP settings are stored at OpenBao `homelab/infrastructure/uptime-kuma/smtp` with keys `server`, `port`, `username` and `token`. Task 4 reads all four, and the `uptime-kuma-vps` policy gains read on `homelab/data/infrastructure/uptime-kuma/smtp`.
+
+## Original open questions (kept for reference)
+
+1. **Where the Kuma admin credential lives.** Kuma is single-user. Ansible needs that user to bootstrap the instance, and AutoKuma needs it to log in. Ansible has no OpenBao lookup today (`ansible/` uses Ansible Vault only), so storing it in both places makes two copies. *Recommendation:* OpenBao `infrastructure/uptime-kuma` is the only source, and the play reads it with `community.hashi_vault`, using a Woodpecker secret token that has read access to that one path. This plan assumes that recommendation. If it is rejected, Task 1 Step 2 changes and nothing else does.
+2. **Public DNS.** Neither `netbird.renner.uno` nor `uptime.renner.uno` is defined in this repo (`opentofu/dns_renner_uno.tf` holds LAN records only). `uptime.renner.uno` currently points at UptimeRobot's status-page fleet. Where are these records managed? If it is the Cloudflare UI, Task 1 needs `kuma.renner.uno` created there and Task 5 needs `uptime.renner.uno` repointed there.
+3. **Alert channel.** Alertmanager sends email through `smtp.protonmail.ch:587` as `cluster@renner.uno`. Kuma needs its own SMTP token, because no service shares another's key. *Recommendation:* create a Proton SMTP token for `uptime@renner.uno` (or another address you pick) and store it at OpenBao `infrastructure/uptime-kuma`, key `smtp_password`. Creating the token is a one-time owner action.
+
+## Global Constraints
+
+- Kuma image: `louislam/uptime-kuma:2.5.6-slim`. Pin it in role defaults, the way `netbird_version` is pinned. The controller drives Kuma's **internal Socket.io API**, which upstream says may change without notice. Kuma and AutoKuma are therefore bumped together, and only after the pilot checks from Task 3 pass against the new pair.
+- `UPTIME_KUMA_DB_TYPE=sqlite`. This skips the database setup wizard (`server/setup-database.js:98`).
+- Kuma data lives at `/opt/uptime-kuma/data` (container `/app/data`) on local disk. Not NFS.
+- Hostnames: `kuma.renner.uno` serves the admin UI and the Socket.io API. `uptime.renner.uno` serves the public status page, through Kuma's custom-domain mapping.
+- Nothing in the Kuma alert path may traverse the homelab.
+- No `2>/dev/null` anywhere. No inline interpreters in Bash. Commits use the claude-bot identity, every change goes through a PR, and nothing is ever force-pushed.
+
+## Review Focus
+
+1. **Socket.io API drift.** AutoKuma 2.0.0 (2025-11) targets an older Kuma 2.x API than 2.5.6. Silent failures (a monitor created with fields dropped) are worse than loud ones. The Task 3 pilot asserts the field values Kuma actually stored, not just that the monitor exists.
+2. **Controller restart duplicates monitors.** AutoKuma tracks ownership by tag and keeps state in `/data`. A pod restart with an empty `/data` must not create a second copy of every monitor. Task 3 Step 5 pins this.
+3. **Deleting a `KumaEntity` while the controller is down.** The finalizer `entity.autokuma.bigboot.dev` must hold the object until the controller is back and removes the monitor. Task 3 Step 6 pins this.
+4. **Kuma or VPS down goes unnoticed.** The blackbox probe on `https://kuma.renner.uno` plus its alert rule (Task 4) is the dead-man switch. Task 4 Step 4 proves the alert fires.
+5. **Unclaimed fresh instance.** Between `docker compose up` and admin setup, the first visitor to `kuma.renner.uno` could claim admin. The bootstrap runs in the same play run, before the Traefik route is enabled (Task 1 Step 4).
+
+---
+
+### Task 1: Uptime Kuma on the NetBird VPS (Ansible role, play, pipeline)
+
+**Files:**
+- Create: `ansible/roles/uptime-kuma/defaults/main.yml`
+- Create: `ansible/roles/uptime-kuma/tasks/main.yml`
+- Create: `ansible/roles/uptime-kuma/templates/docker-compose.yml.j2`
+- Create: `ansible/roles/uptime-kuma/files/kuma-setup.js`
+- Create: `ansible/plays/install-uptime-kuma.yml`
+- Create: `.woodpecker/deploy-uptime-kuma.yml`
+
+**Interfaces:**
+- Produces: `https://kuma.renner.uno` (Kuma UI and Socket.io), with the admin user from OpenBao `infrastructure/uptime-kuma` keys `username` and `password`. Task 3 consumes these.
+
+- [ ] **Step 1: Role defaults.** Set `uptime_kuma_version: "2.5.6"`, `uptime_kuma_host: kuma.renner.uno`, `uptime_kuma_status_host: uptime.renner.uno`, `uptime_kuma_dir: /opt/uptime-kuma`, and `uptime_kuma_traefik_network: netbird_netbird`. The last one is the network the NetBird Traefik watches (`ansible/roles/netbird-server/templates/docker-compose.yml.j2`, docker provider).
+- [ ] **Step 2: Credentials.** Look up `username` and `password` from OpenBao `infrastructure/uptime-kuma` with `community.hashi_vault`. Add the collection to the CI image only if `ci-ansible:2026-04-29` lacks it; check with `ansible-galaxy collection list` in that image. Store the Woodpecker secret `openbao_uptime_kuma_token`, and give it a policy that reads that one path.
+- [ ] **Step 3: Compose template.** One service, `uptime-kuma`, using image `louislam/uptime-kuma:{{ uptime_kuma_version }}-slim`. Environment `UPTIME_KUMA_DB_TYPE=sqlite`, volume `{{ uptime_kuma_dir }}/data:/app/data`, external network `{{ uptime_kuma_traefik_network }}`. Traefik labels: `traefik.enable={{ uptime_kuma_route_enabled }}` and a router on `Host(kuma.renner.uno) || Host(uptime.renner.uno)` with `tls.certresolver=letsencrypt` and server port 3001.
+- [ ] **Step 4: Bootstrap with no manual step.** `files/kuma-setup.js` uses `socket.io-client`, which is a production dependency of Kuma 2.5.6 and so present in the image. It connects to `http://localhost:3001`, emits `needSetup`, and if the answer is true emits `setup(username, password)`. If the answer is false it exits 0. It reads the credentials from env vars `KUMA_SETUP_USERNAME` and `KUMA_SETUP_PASSWORD`, never from arguments. The tasks run in this order:
+  1. Template compose with `uptime_kuma_route_enabled: false`, then `docker compose up -d`.
+  2. Wait for `GET http://127.0.0.1:3001` (published on loopback only) to return 200.
+  3. Copy the script in and run it with `docker compose exec -e ... uptime-kuma node /tmp/kuma-setup.js`.
+  4. Re-template with the route enabled and run `docker compose up -d` again.
+- [ ] **Step 5: Play and pipeline.** `plays/install-uptime-kuma.yml` targets hosts `netbird_server` with roles `uptime-kuma`. `docker-install` is already applied by the NetBird play. `.woodpecker/deploy-uptime-kuma.yml` is a copy of `.woodpecker/deploy-netbird-server.yml` with its paths and play swapped, and it adds the OpenBao token secret.
+- [ ] **Step 6: Verify.**
+  - Run `ansible-playbook --syntax-check -i ansible/inventory ansible/plays/install-uptime-kuma.yml`. Expected: no errors.
+  - After the pipeline runs, `curl -sI https://kuma.renner.uno/` returns `302` to `/dashboard`. A `/setup` response means the bootstrap failed.
+  - Run the pipeline a second time. Expected: it is green and the script logs "already set up".
+- [ ] **Step 7: Commit and open a PR.** Message: `feat(uptime-kuma): Uptime Kuma on the NetBird VPS`.
+
+### Task 2: Controller deployment (AutoKuma, Kubernetes source)
+
+**Files:**
+- Create: `kubernetes/apps/autokuma/{crd-kumaentities.yaml,externalsecret.yaml,rbac.yaml,deployment.yaml,kustomization.yaml}`
+- Create: `kubernetes/clusters/homelab/autokuma.yaml`
+- Create: `kubernetes/infrastructure/network-policies/autokuma-ns.yaml`
+- Modify: `kubernetes/infrastructure/namespaces/namespaces.yaml`. Add namespace `autokuma`.
+
+**Interfaces:**
+- Consumes: Task 1's `https://kuma.renner.uno` and the OpenBao `infrastructure/uptime-kuma` `username`/`password`.
+- Produces: the CRD `kumaentities.autokuma.bigboot.dev/v1` (namespaced, `spec.config` is a free-form object). Monitors live as `KumaEntity` objects in namespace `autokuma`. `metadata.name` is the AutoKuma ID, and `spec.config` uses the static-monitor keys (`type`, `name`, `url`, …).
+
+- [ ] **Step 1: Vendor the CRD.** Copy it verbatim from `https://raw.githubusercontent.com/BigBoot/AutoKuma/v2.0.0/autokuma/kubernetes/crds-autokuma.yml`, with a one-line header naming the source and the tag.
+- [ ] **Step 2: RBAC.** AutoKuma lists and watches `Api::<KumaEntity>::all` (`kubernetes_source.rs`, `init`), so a namespaced Role cannot satisfy it. Create a ClusterRole limited to `kumaentities` with `get, list, watch, patch, update`, plus a ClusterRoleBinding to ServiceAccount `autokuma/autokuma`. No other resources.
+- [ ] **Step 3: ExternalSecret.** Use ClusterSecretStore `openbao`, key `infrastructure/uptime-kuma`, properties `username` and `password`, rendered into a Secret named `autokuma-kuma`. Copy the CEL health-check pattern from `kubernetes/clusters/homelab/uptime-monitor.yaml`.
+- [ ] **Step 4: Deployment.** Image `ghcr.io/bigboot/autokuma:2.0.0`, 1 replica, strategy `Recreate`. Environment:
+  - `AUTOKUMA__KUMA__URL=https://kuma.renner.uno`
+  - `AUTOKUMA__KUMA__USERNAME` and `AUTOKUMA__KUMA__PASSWORD` from the Secret
+  - `AUTOKUMA__KUBERNETES__ENABLED=true`
+  - `AUTOKUMA__DOCKER__ENABLED=false`
+  - `AUTOKUMA__TAG_NAME=AutoKuma`
+  - `AUTOKUMA__ON_DELETE=delete`
+
+  Mount an `emptyDir` at `/data`. Add the security context from `kubernetes/apps/uptime-monitor/deployment.yaml`, and the reloader annotation for `autokuma-kuma`.
+- [ ] **Step 5: NetworkPolicy.** Copy `uptime-monitor-ns.yaml`: default-deny, DNS to kube-dns, `kube-apiserver`, and `world` on TCP 443.
+- [ ] **Step 6: Flux Kustomization.** Path `./kubernetes/apps/autokuma`, `prune: true`, `wait: true`, `dependsOn` `infrastructure` and `infrastructure-crds`. It ships with **no** `KumaEntity` objects.
+- [ ] **Step 7: Verify.**
+  - `kubectl kustomize kubernetes/apps/autokuma` renders.
+  - After merge, `kubectl -n autokuma logs deploy/autokuma` shows a successful Kuma login and no "CRD is not queryable".
+  - `flux get kustomization autokuma` reports Ready.
+- [ ] **Step 8: Commit and open a PR.** Message: `feat(autokuma): KumaEntity controller for Uptime Kuma`.
+
+### Task 3: Pilot gate — does AutoKuma meet the bar?
+
+**Files:**
+- Create: `kubernetes/apps/autokuma/pilot-kumaentities.yaml`. Add it to the kustomization last.
+
+**Interfaces:**
+- Consumes: Task 2's CRD and controller.
+- Produces: a go/no-go verdict, recorded in the PR description. **No-go stops this plan.** The fallback is our own controller against the same CRD shape, under a separate plan.
+
+- [ ] **Step 1: Pilot entity.** Create `KumaEntity` `www-renner-uno` with `config: {type: keyword, name: "www.renner.uno", url: "https://www.renner.uno/", keyword: "<a string present on the page>", interval: 60, expiry_notification: true}`. Check the field names against `https://autokuma.bigboot.dev/dev/entity-types/keyword/` before writing them.
+- [ ] **Step 2: Fields arrive intact.** In the Kuma UI, or with `kuma monitor list` from the AutoKuma CLI, confirm `type=keyword`, the keyword, `interval=60` and certificate-expiry notification are all as declared. Expected: all four match. Any dropped field is a **no-go**.
+- [ ] **Step 3: Update.** Change `interval` to 120 in git. Expected: Kuma shows 120 within one reconcile (≤ 5 min), and the monitor ID is unchanged.
+- [ ] **Step 4: Detailed types.** Add one `json-query` entity, one `dns` entity, and one `port` entity on `proxy-1.renner.uno:33080`. Expected: all three are created with their type-specific fields intact.
+- [ ] **Step 4a: Groups.**
+  - Add a `group` entity `pilot` and set `parent_name: pilot` on every pilot check. Expected: in Kuma, all checks sit under the group, and the group goes DOWN when one child is pointed at a non-existent path. A group is DOWN when any child is DOWN (`server/monitor-types/group.js`).
+  - Add a group `pilot-inner` with `parent_name: pilot`, and move one check under it. Record whether nesting works. If it doesn't, Task 5 uses a flat layout with one group per service, which is not a no-go.
+- [ ] **Step 4b: JSON query intact.** Read back the `json-query` entity's `json_path`, `json_path_operator` and `expected_value` from Kuma. Use a non-default operator such as `>=`, so that a dropped field shows up as the default `==`. Expected: all three match the values declared in git.
+- [ ] **Step 5: Restart without duplicates.** Delete the AutoKuma pod, which empties `/data`. Expected: after it restarts, Kuma still holds exactly one monitor per entity.
+- [ ] **Step 6: Deletion while the controller is down.** Scale the controller to 0, delete the `port` entity in git, wait for Flux, then scale back to 1. Expected: the object sits `Terminating` with the finalizer while the controller is down, and the Kuma monitor is removed after scale-up. An orphaned monitor is a **no-go**.
+- [ ] **Step 7: Verdict.** If Steps 2–6 all pass, the verdict is **go**: commit the pilot entities and open a PR with the evidence. Otherwise it is **no-go**: revert the pilot and report which step failed.
+
+### Task 4: Notifications, status page, dead-man switch
+
+**Files:**
+- Modify: `ansible/roles/uptime-kuma/files/kuma-setup.js`. Add the SMTP notification: host, port, user and password from OpenBao `homelab/infrastructure/uptime-kuma/smtp` keys `server`, `port`, `username` and `token`, sender `uptime@renner.uno`, "default enabled", applied to all monitors. `KumaEntity.spec.config` is plain text in git, so the secret-bearing notification is created by the bootstrap and never by a custom resource.
+- Create: `kubernetes/apps/autokuma/status-page.yaml` (a `KumaEntity` status page with slug `renner`, domain `uptime.renner.uno`)
+- Modify: `kubernetes/apps/monitoring-rules/probes-blackbox.yaml`. Add `https://kuma.renner.uno` to `blackbox-http`.
+- Modify: the alert-rule file that covers `blackbox-http` targets. Find it with Grep for `probe_success` under `kubernetes/apps/monitoring-rules/`.
+
+- [ ] **Step 1: Check the status-page entity.** Check AutoKuma's status-page entity docs for field names and domain support. If AutoKuma cannot set the status-page domain, have `kuma-setup.js` set it instead, keeping the value in the role defaults.
+- [ ] **Step 2: Notification.** Extend `kuma-setup.js` so it creates the notification if none named `email` exists, and updates it otherwise. Run the Task 1 pipeline. Expected: in the Kuma UI, *Test* delivers a mail to the owner's address, and a second pipeline run creates no duplicate.
+- [ ] **Step 3: Status page.** Apply it. Expected: `curl -s -H 'Host: uptime.renner.uno' https://kuma.renner.uno/` returns the status page HTML, not the dashboard redirect. Turn on Kuma's "Trust Proxy" setting through the same mechanism as the domain.
+- [ ] **Step 4: Dead-man switch.** Add the blackbox target and make sure an alert rule covers it. Prove it fires: stop the Kuma container on the VPS through the pipeline (or have the owner do it). Expected: the alert email arrives through Alertmanager. Then start Kuma again.
+- [ ] **Step 5: Response-time alerting.** Kuma 2.5.6 has no latency threshold; its states are only UP, DOWN, PENDING and MAINTENANCE. Degradation is therefore alerted from the cluster:
+  - `kuma-setup.js` creates a Kuma metrics API key named `prometheus` if none exists, and writes it to OpenBao `infrastructure/uptime-kuma-metrics` key `api_key`. The Ansible token gets write access to that one path. No other service's credential is reused.
+  - Add an ExternalSecret into `monitoring` for that key, and an `additionalScrapeConfigs` job `uptime-kuma` in `kubernetes/apps/monitoring/helmrelease-prometheus.yaml`: target `kuma.renner.uno:443`, `scheme: https`, `basic_auth` with an empty username and the key as `password_file`.
+  - Check that the `monitoring` namespace egress policy lets Prometheus reach `world:443`, and add the rule if it doesn't.
+  - Add a PrometheusRule `UptimeKumaSlowResponse` on `monitor_response_time` (label `monitor_name`): `avg_over_time(monitor_response_time[15m]) > 1500` for 15m, severity warning. Check the metric name against a live scrape before writing the rule.
+  - Expected: `monitor_response_time` series are visible in Prometheus for every Kuma monitor, and the rule loads without errors.
+- [ ] **Step 6: Commit and open a PR.** Message: `feat(autokuma): notifications, status page, Kuma dead-man probe, latency alerting`.
+
+### Task 5: Migrate monitors, cutover, decommission UptimeRobot
+
+**Files:**
+- Create: `kubernetes/apps/autokuma/monitors-*.yaml`. One file per area, one `KumaEntity` per check.
+- Delete (in the decommission PR): `kubernetes/apps/uptime-monitor/`, `kubernetes/clusters/homelab/uptime-monitor.yaml`, `kubernetes/infrastructure/network-policies/uptime-monitor-ns.yaml`, and the `uptime-monitor` namespace entry.
+
+- [ ] **Step 1: Inventory.** Take the 9 hand-made monitors from UptimeRobot's public feed. Its path is in the header of `kubernetes/apps/uptime-monitor/pilot-endpointmonitors.yaml`. Each monitored service becomes one `group` entity with its checks as children, nested or flat depending on Task 3 Step 4a.
+  - Every check sets `accepted_statuscodes` and a tight `timeout`, so "far too slow" counts as DOWN.
+  - Where the service has a health or API endpoint, use `json-query` with a JSONata expression that validates the parsed content (example: `$count(components[status != "ok"])` `==` `0`).
+  - Otherwise use `keyword` on a string that only a working page renders. Keyword matching is a case-sensitive substring, not a regex.
+  - `expiry_notification: true` on every HTTPS check.
+  - The 3 third-party monitors move as plain checks.
+- [ ] **Step 2: Parallel run.** Merge the monitors and run both systems for 7 days. Expected: Kuma reports every outage UptimeRobot reports.
+- [ ] **Step 3: Cutover.** Repoint `uptime.renner.uno` at the VPS (see open question 2). Expected: `curl -sI https://uptime.renner.uno/` is served by Kuma with a Let's Encrypt certificate.
+- [ ] **Step 4: Decommission PR.** Remove the IMC files listed above in one PR. Monitors deleted along with the CRD are orphaned in UptimeRobot. That is acceptable, because the account is closed next.
+- [ ] **Step 5: Owner action.** Close the UptimeRobot account. Delete the OpenBao key `infrastructure/uptime-robot`.
+- [ ] **Step 6: Wiki.** Deposit the final architecture through `wiki-ingest`: the corrected `uptime-kuma-probes` note, the Socket.io-API pinning rule, and the dead-man switch.
@@ -0,0 +1,47 @@
+# kuma-sync — in-house Uptime Kuma controller (design)
+
+## Why
+
+AutoKuma failed the pilot gate (plan `2026-10-18-uptime-kuma.md`, Task 3). It never applied its ownership tag against Uptime Kuma 2.5.6, so ownership lived only in the pod's local `/data`, and every restart duplicated every monitor. Its CRD is also untyped (`spec.config: object`), so typos are only noticed when a monitor silently misbehaves. The owner decided to replace it with an in-house controller.
+
+## Goals
+
+- Uptime Kuma monitors are declared in git as **typed** Kubernetes resources, validated by the API server when they are applied.
+- **Ownership is stored in Kuma itself**: a tag on each managed monitor. Restart, cluster rebuild or a lost pod state never duplicates or orphans a monitor.
+- The controller converges on its own: creation order (groups before children), drift (a monitor edited in the UI is set back), and deletion (including deletion while the controller was down).
+- It supports the detailed checks the owner asked for: groups with nesting, HTTP status codes, keyword (with invert), JSON query (JSONata expression + operator + expected value), DNS, TCP port, push, certificate-expiry notification, and timeouts per check.
+
+## Non-goals
+
+- Notifications and status pages are not managed as resources (Task 4 of the parent plan creates them via the Ansible bootstrap). Monitors reference notifications by name only if Task 4 needs it; not in v1.
+- No support for other Kuma versions than the pinned one. Kuma and the client library are bumped together.
+- No Ingress-driven auto-monitors. Every monitor is an explicit resource.
+
+## Anti-goals
+
+- Never touch a Kuma monitor that does not carry this controller's tag (hand-made monitors stay untouched).
+- No local state the controller depends on. Restarting with nothing but the cluster and Kuma must give the same result.
+
+## Decisions (owner)
+
+- Language: Go.
+- Typed CRD.
+- Ownership via a Kuma tag.
+
+## Decisions (my calls, open to review)
+
+- **Name** `kuma-sync`, source in `ci/images/kuma-sync/` (house pattern: `netbird-service-sync`), image `gitea.renner.uno/gitea_admin/kuma-sync`, built by kaniko in `.woodpecker/build-ci-images.yml`, rolled out by Flux image automation.
+- **Kuma client**: `github.com/breml/go-uptime-kuma-client` v0.6.2 (MIT, tested against Kuma 2.5.6), pinned, with its `replace` for the go.socket.io fork copied into our `go.mod`. Wrapped behind a small internal interface so the reconciler can be tested against a fake and the library can be swapped.
+- **CRD** `KumaMonitor`, group `uptime.renner.uno`, version `v1alpha1`, namespaced, generated by `controller-gen` from Go types with kubebuilder markers. One kind with `spec.type` (enum) and one optional block per type; CEL rules enforce that exactly the block matching `type` is set. Groups are `KumaMonitor`s of type `group`; children reference them with `spec.parentRef.name` (same namespace).
+- **Ownership tag**: Kuma tag named `kuma-sync`, value `<namespace>/<name>` of the resource. Not the UID: a rebuilt cluster creates new UIDs and must adopt the existing monitors.
+- **Reconcile**: find the monitor by tag value → none: create, then tag → exists: compare the desired fields with the actual ones and edit if they differ (full-object `editMonitor`, as Kuma requires). Parent not created yet → requeue after 10 s, not minutes.
+- **Deletion**: a finalizer deletes the Kuma monitor. A periodic garbage collection (every resync) deletes tagged monitors whose resource no longer exists, which also covers deletion while the controller was down.
+- **Resync** every 5 minutes, to repair drift.
+- **Scope**: watches `KumaMonitor` cluster-wide (apps can declare their own monitors in their namespace). ClusterRole limited to `kumamonitors`, `kumamonitors/status`, `kumamonitors/finalizers` and `events`. Credentials come from a Secret in its own namespace.
+- **Network**: egress only to DNS, kube-apiserver and `kuma.renner.uno:443` (FQDN policy, same as the AutoKuma one the owner asked for).
+- **Single replica, Recreate, no leader election** (house pattern from the IngressMonitorController deployment).
+- **Tests**: unit tests for the reconciler against a fake Kuma; CRD validation tests with envtest; integration tests (build tag `integration`) against a real `louislam/uptime-kuma:2.5.6-slim` container via testcontainers-go. The integration suite reproduces the AutoKuma pilot: fields intact, update, groups + nesting, json-query operator, restart without duplicates, deletion while down.
+
+## Left to the builder
+
+Internal package layout, naming inside the code, log format, metric names.
@@ -6,18 +6,31 @@ below (like `wp-pg`) keeps `bootstrap.recovery` in git: a cold rebuild restores
 each from its backup with no manual step. This document covers the
 precondition, watching and verifying that restore, and the reasoning behind it.

-| Cluster   | Namespace      | ObjectStore     | barman path (`destinationPath`)     | app DB / owner                  |
-|-----------|----------------|-----------------|--------------------------------------|---------------------------------|
-| `ak-pg`   | authentik      | `ak-pg-store`   | `s3://renner-uno-k8s-cnpg/ak-pg`     | `authentik`/`authentik`         |
-| `im-pg`   | immich         | `im-pg-store`   | `s3://renner-uno-k8s-cnpg/im-pg`     | `immich`/`immich`               |
-| `pprl-pg` | paperless      | `pprl-pg-store` | `s3://renner-uno-k8s-cnpg/pprl-pg`   | `paperless`/`paperless`         |
-| `ha-pg`   | home-assistant | `ha-pg-store`   | `s3://renner-uno-k8s-cnpg/ha-pg`     | `homeassistant`/`homeassistant` |
-| `mx-pg`   | matrix         | `mx-pg-store`   | `s3://renner-uno-k8s-cnpg/mx-pg`     | `synapse`/`synapse`             |
-| `tr-pg`   | trmnl          | `tr-pg-store`   | `s3://renner-uno-k8s-cnpg/tr-pg`     | `terminus`/`terminus`           |
+| Cluster   | Namespace      | app DB / owner                  |
+|-----------|----------------|---------------------------------|
+| `ak-pg`   | authentik      | `authentik`/`authentik`         |
+| `im-pg`   | immich         | `immich`/`immich`               |
+| `pprl-pg` | paperless      | `paperless`/`paperless`         |
+| `ha-pg`   | home-assistant | `homeassistant`/`homeassistant` |
+| `mx-pg`   | matrix         | `synapse`/`synapse`             |
+| `tr-pg`   | trmnl          | `terminus`/`terminus`           |
+| `wp-pg`   | woodpecker     | `woodpecker`/`woodpecker`       |

-The barman **`serverName`** is the last path segment of `destinationPath`, i.e.
-it equals the cluster name. `gf-pg` (monitoring) has no ObjectStore and stays
-on `initdb`.
+Each cluster `<x>` has two ObjectStores in `kubernetes/cnpg-object-stores/`:
+`<x>-store`, where it archives WAL and takes base backups, and
+`<x>-store-source`, which `bootstrap.recovery` reads. Their paths come from the
+`flux-system/cnpg-paths` ConfigMap, which `bootstrap.sh` writes once per
+cluster incarnation: the source is the prefix in `s3://renner-uno-k8s-cnpg`
+whose `<x>/base/` holds the newest base backup, the archive a new prefix
+`<x>-g<timestamp>`. The barman **`serverName`** is the cluster name in both.
+`gf-pg` (monitoring) has no ObjectStore and stays on `initdb`.
+
+The current prefixes: `kubectl -n flux-system get cm cnpg-paths -o yaml`
+(`CNPG_<X>_SOURCE`, `CNPG_<X>_ARCHIVE`). `bootstrap.sh` never rewrites an
+existing `cnpg-paths`. Adding a CNPG cluster to a running cluster therefore
+means adding its two keys to that ConfigMap by hand, with the archive prefix
+as the source as well; without them `cnpg-object-stores` fails to build and
+every app Kustomization behind it stalls.

 ---

@@ -52,12 +65,16 @@ Example uses `ak-pg`; substitute the row from the table above for the others.
 ### 1. Precondition — confirm a backup actually exists

 Never start a recovery you can't finish. Check the object store has a base
-backup and recent WAL for the cluster's `serverName` before touching anything:
+backup and recent WAL for the cluster's `serverName` before touching anything.
+Backups live under `<prefix>/<serverName>/base/`, one prefix per incarnation
+(`ak-pg` and `ak-pg-g<timestamp>`):

 ```sh
 # From a machine with the Hetzner S3 creds (see hetzner-creds-externalsecret):
 aws --endpoint-url https://fsn1.your-objectstorage.com \
-    s3 ls s3://renner-uno-k8s-cnpg/ak-pg/base/
+    s3 ls s3://renner-uno-k8s-cnpg/ | grep ak-pg
+aws --endpoint-url https://fsn1.your-objectstorage.com \
+    s3 ls s3://renner-uno-k8s-cnpg/<prefix>/ak-pg/base/
 ```

 If that is empty, **stop** — recovery will hang forever (no initdb fallback).
@@ -73,9 +90,10 @@ drives the restore.
  brings back *all* databases and roles, not just the app DB. The
  `database`/`owner` fields only tell CNPG which app user the `-app` service
  should target after promotion.
- After the restored primary is promoted, CNPG bumps the PostgreSQL timeline
-  and `spec.plugins[].isWALArchiver: true` resumes archiving to the same
-  `serverName` path without clobbering the old WAL.
+- After the restored primary is promoted, `spec.plugins[].isWALArchiver: true`
+  archives to `<x>-store`, the new incarnation's own empty prefix; the
+  prefix it recovered from is left untouched. Its first base backup there is
+  taken right away (`immediate: true` on the ScheduledBackup).

 ```sh
 kubectl -n authentik get cluster ak-pg -w
@@ -365,10 +365,25 @@ kubernetes/bootstrap.sh wait-apps
 ```

 Waits per-app (apps, authentik, monitoring, paperless, home-assistant, immich,
-etc., each absorbing its seed Job) and then waits for all cert-manager
-Certificates to issue. Stateful apps restore from their seed KSes / backups
-(CNPG DBs, migrating PVCs). Long tails are expected (immich library seed rsync
-~26 min). End-to-end health check: `bash kubernetes/e2e-test.sh`.
+etc.) and then waits for all cert-manager Certificates to issue. The volumes
+come back by themselves: each Velero Schedule has a `restore-<schedule>`
+Kustomization (`clusters/homelab/restore.yaml`) that applies a Velero Restore
+of the schedule's newest backup, `restore-gitea` first, and every app waits
+for its own. CNPG databases recover from barman (`RECOVERY.md`). Long tails
+are expected (immich's library). End-to-end health check:
+`bash kubernetes/e2e-test.sh`.
+
+A Restore runs once and is never retried. One that ends `PartiallyFailed`,
+`Failed` or `FailedValidation` (other than "No backups found for schedule")
+keeps its `restore-*` Kustomization not Ready, and every Kustomization that
+depends on it stops applying, until the Restore is gone. The Restore of
+`restore-<name>` is `velero/<name>`. Read its result, fix the cause, then
+delete it; Flux applies it again against the newest backup:
+
+```sh
+velero restore describe <name> --details
+kubectl -n velero delete restore <name>
+```

 ## Step 6 — switch the Flux source back to Gitea

@@ -131,7 +131,7 @@ data:
        state: absent

      # shelly-manager.home.renner.uno is gated by authentik-gate-sync
-      # (kubernetes/apps/home-assistant/shelly-manager-ingress.yaml), which
+      # (kubernetes/apps/home-assistant-iot/shelly-manager-ingress.yaml), which
      # admits this group. Members are managed in Authentik.
      - model: authentik_core.group
        identifiers:
@@ -450,7 +450,7 @@ data:
      # synthesise the entry by creating a service-account user
      # whose user.attributes carry the sambaDomain objectClass
      # and the required schema fields. The patched LDAP outpost
-      # (gitea.renner.uno/k.renner/authentik-samba-bridge-ldap-outpost)
+      # (gitea.renner.uno/konairius/authentik-samba-bridge-ldap-outpost)
      # accepts sambaDomain in its hardcoded GetUserOCs() set so the
      # search isn't short-circuited. The sambaSID below MUST match
      # SAMBA_BRIDGE_DOMAIN_SID in samba-bridge-secret.sops.yaml AND
@@ -711,8 +711,8 @@ data:
            # AND (&(sambaDomainName=...)(objectClass=sambaDomain))
            # return entries instead of short-circuiting. Built from
            # the samba-bridge repo at
-            # gitea.renner.uno/k.renner/authentik-samba-bridge .
-            container_image: gitea.renner.uno/k.renner/authentik-samba-bridge-ldap-outpost:2026.8.3-872f754
+            # gitea.renner.uno/konairius/authentik-samba-bridge .
+            container_image: gitea.renner.uno/konairius/authentik-samba-bridge-ldap-outpost:2026.8.3-9dd92dd
            object_naming_template: "ak-outpost-%(name)s"
            kubernetes_namespace: authentik
            kubernetes_replicas: 1
@@ -47,7 +47,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: ak-pg-store
+          barmanObjectName: ak-pg-store-source
          serverName: ak-pg
  postgresql:
    parameters:
@@ -20,7 +20,7 @@ spec:
      # Pinned to match the samba-bridge fork's app image (server.Dockerfile
      # AUTHENTIK_VERSION). Bump in lockstep with the bridge rebuild — a
      # floating range drifts the chart ahead of the pinned app image.
-      version: "2026.8.3"
+      version: "2026.8.4"
      sourceRef:
        kind: HelmRepository
        name: authentik
@@ -47,9 +47,9 @@ spec:
      # in the configured Synology Users group, so the LDAP outpost
      # then emits NT-hash-bearing user entries that DSM's smbd
      # accepts for NTLMv2 SMB authentication. See
-      # https://gitea.renner.uno/k.renner/authentik-samba-bridge .
+      # https://gitea.renner.uno/konairius/authentik-samba-bridge .
      image:
-        repository: gitea.renner.uno/k.renner/authentik-samba-bridge-server
+        repository: gitea.renner.uno/konairius/authentik-samba-bridge-server
        # Pinned to a specific build for two reasons:
        # 1. K8s does not pull on every reschedule when tag=latest, so
        #    a floating tag means we don't actually pick up rebuilds
@@ -57,8 +57,8 @@ spec:
        #    "no pod invasion" rule).
        # 2. Pinning means the deployed binary is traceable to a
        #    specific repo commit. Bump the tag whenever a new build
-        #    is published from gitea.renner.uno/k.renner/authentik-samba-bridge .
-        tag: "2026.8.3-872f754"
+        #    is published from gitea.renner.uno/konairius/authentik-samba-bridge .
+        tag: "2026.8.3-9dd92dd"
      envFrom:
        # SAMBA_BRIDGE_DOMAIN_SID / _ENABLED_GROUP / _UID_OFFSET
        # consumed by the bridge module at Django app startup. Missing
@@ -152,10 +152,11 @@ spec:
        targetCPUUtilizationPercentage: 70
      metrics:
        enabled: true
+        # The chart renders it without checking for monitoring.coreos.com, so
+        # the install would wait on monitoring. Declared in
+        # monitoring-rules/authentik-servicemonitor.yaml instead.
        serviceMonitor:
-          enabled: true
-          labels:
-            release: kube-prometheus-stack
+          enabled: false
      ingress:
        enabled: true
        ingressClassName: traefik
@@ -11,10 +11,9 @@ resources:
  - ldap-outpost-cnp.yaml
  # ak-pg CNPG Postgres backend (moved here from the retired seed-authentik KS;
  # each carries prune: disabled so ownership transferred without a teardown).
-  # authentik has no data PVCs — all state lives in ak-pg. This KS gains the
-  # infrastructure-cnpg-barman dep + CNPG Cluster healthCheckExprs (see
+  # authentik has no data PVCs — all state lives in ak-pg. This KS depends on
+  # cnpg-object-stores and health-checks the CNPG Cluster (see
  # clusters/homelab/authentik.yaml).
  - cluster.yaml
-  - objectstore.yaml
  - scheduled-backup.yaml
  - hetzner-creds-externalsecret.yaml
@@ -1,33 +0,0 @@
---
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: ak-pg-store
-  namespace: authentik
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->authentik-KS handoff (backup target).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  configuration:
-    # Offsite Hetzner Object Storage (fsn1) — replaces Garage on nas-1.
-    # No SSE: Hetzner supports only SSE-C, unusable by barman-cloud
-    # (plugin #646), so at-rest encryption is unavailable; transit is TLS.
-    destinationPath: s3://renner-uno-k8s-cnpg/ak-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      # Region is required (REGION=fsn1) — without it boto3's HeadBucket
-      # (barman-cloud-check-wal-archive during bootstrap.recovery) 400s.
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  retentionPolicy: "30d"
@@ -23,7 +23,7 @@ spec:
          type: RuntimeDefault
      containers:
        - name: gitea-mcp
-          image: docker.gitea.com/gitea-mcp-server:1.9.0 # {"$imagepolicy": "flux-system:gitea-mcp"}
+          image: docker.gitea.com/gitea-mcp-server:1.10.0 # {"$imagepolicy": "flux-system:gitea-mcp"}
          # Image has no ENTRYPOINT (binary is in CMD), so args alone would replace it.
          command:
            - /app/gitea-mcp
@@ -50,6 +50,50 @@ spec:
            - port: "3000"
              protocol: TCP
 ---
+# Secret rotation: the registry-bot rotator mints registry-bot's PAT. Egress half:
+# rotator-registry-bot-egress in network-policies/openbao-ns.yaml.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: gitea-allow-registry-bot-rotator
+  namespace: gitea
+spec:
+  endpointSelector:
+    matchLabels:
+      app.kubernetes.io/name: gitea
+  ingress:
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": openbao
+            app.kubernetes.io/component: secret-rotator
+            app.kubernetes.io/name: registry-bot
+      toPorts:
+        - ports:
+            - port: "3000"
+              protocol: TCP
+---
+# Secret rotation: the ha-config-sync rotator mints ha-config-sync's PAT. Egress
+# half: rotator-ha-config-sync-egress in network-policies/openbao-ns.yaml.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: gitea-allow-ha-config-sync-rotator
+  namespace: gitea
+spec:
+  endpointSelector:
+    matchLabels:
+      app.kubernetes.io/name: gitea
+  ingress:
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": openbao
+            app.kubernetes.io/component: secret-rotator
+            app.kubernetes.io/name: ha-config-sync
+      toPorts:
+        - ports:
+            - port: "3000"
+              protocol: TCP
+---
 # Package retention CronJob (package-retention.yaml, REN-1203). It lists pods
 # to find the running image tags. The namespace baseline does not open the API
 # server: `kube-apiserver` is its own entity in Cilium; port is the post-DNAT
@@ -10,10 +10,8 @@
 # - Name, namespace, accessModes, storageClassName and volumeMode must match
 #   the live claim exactly: they are immutable, a mismatch fails the whole
 #   gitea Kustomization (no change to the live claim).
-# - volumeName must stay: kustomize-controller has owned spec.volumeName
-#   since the namespace move pre-created this claim (eb23d3ac, #878).
-#   Without it, server-side apply tries to clear the field and the API server
-#   rejects the whole claim as an immutable-spec change.
+# - No volumeName: the gitea Kustomization ignores /spec/volumeName on this
+#   claim, so the bound volume is kept and a fresh cluster binds a new one.
 # - Grow only. A smaller value is rejected by the API server.
 # - prune: disabled, so removing this file from git never deletes the claim
 #   and its data. To hand ownership back, delete the file; the claim stays.
@@ -33,7 +31,6 @@ spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ceph-block
  volumeMode: Filesystem
-  volumeName: pvc-e7c56db2-481d-40cb-b94a-b264b7b4b5be
  resources:
    requests:
      storage: 60Gi
@@ -0,0 +1,35 @@
+# The home-assistant workloads attached to the IoT VLAN (v30iot). Separate from
+# ../home-assistant so that HA and what depends on it do not wait on a VLAN
+# the node may not have; the pods run only where it does
+# (net.renner.uno/iot-vlan).
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - shelly-manager-pvc.yaml
+  - shelly-manager-network-attachment.yaml
+  - shelly-manager-firmware-rbac.yaml
+  - shelly-ble-proxy-key-externalsecret.yaml
+  # shelly-manager-auth comes from ../home-assistant: mqtt-account-controller
+  # mounts it too, and that Kustomization comes first.
+  - shelly-manager-llat-externalsecret.yaml
+  - shelly-manager-deployment.yaml
+  - shelly-manager-service.yaml
+  - shelly-manager-ingress.yaml
+  # mDNS relay — carries IoT-VLAN announcements into HA's zeroconf listener as
+  # unicast, which is the only direction the CNI will move them. Without it HA
+  # never learns that a device's DHCP lease moved. See the header comment in
+  # mdns-relay-deployment.yaml.
+  - mdns-relay-network-attachment.yaml
+  - mdns-relay-service.yaml
+  - mdns-relay-deployment.yaml
+configMapGenerator:
+  # shelly-manager api-proxy sidecar config (REN-935). Hash suffix disabled
+  # (name stays stable), so editing shelly-manager-api-proxy.conf does not
+  # auto-roll the pod — restart manually with
+  # `kubectl rollout restart deploy/shelly-manager -n home-assistant`.
+  - name: shelly-manager-api-proxy
+    namespace: home-assistant
+    files:
+      - api.conf.template=shelly-manager-api-proxy.conf
+generatorOptions:
+  disableNameSuffixHash: true
@@ -47,6 +47,9 @@ spec:
        homelab.renner.uno/restarted-for: "2026-10-06 cni-plugins v1.9.1 attach check"
        k8s.v1.cni.cncf.io/networks: mdns-relay-iot
    spec:
+      # Runs where the node patch declares the IoT VLAN (ens19).
+      nodeSelector:
+        net.renner.uno/iot-vlan: "true"
      enableServiceLinks: false
      securityContext:
        runAsNonRoot: true
@@ -47,10 +47,10 @@ spec:
    spec:
      # eth0 (Cilium-managed pod network) is still the primary — it
      # carries the ingress, mosquitto LB return path, etc. The macvlan
-      # above is additive. No explicit edge exclusion is needed: the
-      # `workload-class=pinned:NoSchedule` taint on k8s-edge already
-      # keeps this pod off there (we never tolerate it), and the NAD's
-      # `master: ens19` (stable predictable name for the v30iot NIC) is present on every k8s-{1,2,3} worker.
+      # above is additive.
+      # Runs where the node patch declares the IoT VLAN (ens19).
+      nodeSelector:
+        net.renner.uno/iot-vlan: "true"
      enableServiceLinks: false
      # Grants shelly-manager the in-cluster identity used by the firmware
      # pipeline to create esphome flash Jobs and stream their logs. RBAC is
@@ -0,0 +1,19 @@
+# Gitea token of the ha-config-sync account for the config-sync sidecar: push
+# `live`, open the live -> main PR. Rotated by openbao/ha-config-sync-secret-rotate.
+apiVersion: external-secrets.io/v1
+kind: ExternalSecret
+metadata:
+  name: home-assistant-config-sync-gitea
+  namespace: home-assistant
+spec:
+  refreshInterval: 1h
+  secretStoreRef:
+    kind: ClusterSecretStore
+    name: openbao
+  target:
+    name: home-assistant-config-sync-gitea
+  data:
+    - secretKey: token
+      remoteRef:
+        key: infrastructure/ha-config-sync
+        property: token
@@ -1,8 +1,7 @@
 #!/bin/sh
 # Home Assistant config-sync sidecar — TWO-WAY.
 #
-# /config is a git checkout of gitea.renner.uno/k.renner/homeassistant on an RWO
-# PVC. This loop keeps the tracked HA config paths in sync with the repo in BOTH
+# /config is a git checkout of $GITEA_URL/$GITEA_REPO on an RWO PVC. This loop keeps the tracked HA config paths in sync with the repo in BOTH
 # directions:
 #
 #   push  — changes made inside HA (code-server edits, HA UI automation/script
@@ -15,8 +14,11 @@
 # files at runtime; two-way merge handles that fine — the drift is committed to
 # `live` (PR'd) and merges cleanly, so it no longer needs excluding. Untracked
 # runtime state (.storage/, *.db, secrets.yaml, tts/, deps/, ...) is still left
-# alone (it isn't tracked). git auth uses the PAT embedded in the PVC's remote
-# URL (also reused for the gitea API to open the PR); reload auth uses $HA_TOKEN.
+# alone (it isn't tracked). Git and the gitea API authenticate as $GITEA_USER
+# with the token in $GITEA_TOKEN_FILE, re-read every loop and passed to git
+# through the environment, so it is never written to the PVC's .git/config.
+# The remote URL is reset from $GITEA_URL/$GITEA_REPO on every start. Reload auth
+# uses $HA_TOKEN.
 #
 # Conflicts are left to git: a merge that conflicts is ABORTED (never written
 # into the live files, which would break HA) and logged for you to resolve in the
@@ -30,6 +32,12 @@ MAIN="${SYNC_BRANCH:-main}"
 LIVE="${SYNC_LIVE_BRANCH:-live}"
 INTERVAL="${SYNC_INTERVAL:-30}"
 HA_URL="${HA_URL:-http://127.0.0.1:8123}"
+GITEA_URL="${GITEA_URL:?GITEA_URL is not set}"
+GITEA_REPO="${GITEA_REPO:?GITEA_REPO is not set}"
+GITEA_USER="${GITEA_USER:?GITEA_USER is not set}"
+GITEA_TOKEN_FILE="${GITEA_TOKEN_FILE:-/run/gitea/token}"
+API="${GITEA_URL}/api/v1/repos/${GITEA_REPO}"
+GITEA_TOKEN=""

 # Tracked HA config paths synced in both directions. www/ is included in full
 # (bespoke cards AND HACS-managed assets) — HACS runtime rewrites are captured to
@@ -85,6 +93,21 @@ reload_lovelace() {
  fi
 }

+# Read the (rotated) token and hand it to git as an HTTP header through the
+# environment (GIT_CONFIG_*), so it never lands in .git/config on the PVC.
+load_auth() {
+  GITEA_TOKEN="$(cat "${GITEA_TOKEN_FILE}" 2>/dev/null || true)"
+  if [ -z "${GITEA_TOKEN}" ]; then
+    log "WARN no token in ${GITEA_TOKEN_FILE}; push, fetch and PRs will fail"
+    unset GIT_CONFIG_COUNT GIT_CONFIG_KEY_0 GIT_CONFIG_VALUE_0
+    return
+  fi
+  GIT_CONFIG_COUNT=1
+  GIT_CONFIG_KEY_0=http.extraHeader
+  GIT_CONFIG_VALUE_0="Authorization: Basic $(printf '%s:%s' "${GITEA_USER}" "${GITEA_TOKEN}" | base64 | tr -d '\n')"
+  export GIT_CONFIG_COUNT GIT_CONFIG_KEY_0 GIT_CONFIG_VALUE_0
+}
+
 # Open a PR live -> main if one isn't already open. gitea returns 422 when a PR
 # for this head already exists (or there's no diff); ignore it.
 ensure_pr() {
@@ -109,13 +132,9 @@ git config --global pack.windowMemory 32m 2>/dev/null || true
 git config --global pack.deltaCacheSize 32m 2>/dev/null || true
 git config --global core.deltaBaseCacheLimit 16m 2>/dev/null || true

-# Derive gitea API base + token from the remote URL (https://user:TOKEN@host/owner/repo.git).
-REMOTE_URL="$(git config --get remote.origin.url 2>/dev/null || echo '')"
-GITEA_TOKEN="$(printf '%s' "${REMOTE_URL}" | sed -n 's#^https://[^:]*:\([^@]*\)@.*#\1#p')"
-GITEA_HOST="$(printf '%s' "${REMOTE_URL}" | sed -n 's#^https://[^@]*@\([^/]*\)/.*#\1#p')"
-REPO_PATH="$(printf '%s' "${REMOTE_URL}" | sed -n 's#^https://[^@]*@[^/]*/\(.*\)\.git$#\1#p')"
-API="https://${GITEA_HOST}/api/v1/repos/${REPO_PATH}"
-[ -z "${GITEA_TOKEN}" ] && log "WARN could not derive gitea token from remote URL; PRs won't be opened"
+# The remote is declared by the manifest, without credentials.
+git remote set-url origin "${GITEA_URL}/${GITEA_REPO}.git"
+log "remote origin = ${GITEA_URL}/${GITEA_REPO}.git (user ${GITEA_USER})"

 # Put HEAD on the live branch without disturbing the working tree (live == current
 # HEAD on first run; persisted across restarts on the PVC).
@@ -126,6 +145,8 @@ git symbolic-ref HEAD "refs/heads/${LIVE}" 2>/dev/null || true

 FIRST=1
 while true; do
+  load_auth
+
  # 1. PUSH: capture live edits to the tracked config paths onto `live`.
  # shellcheck disable=SC2086
  if [ -n "$(git status --porcelain -- ${PATHS} 2>/dev/null)" ]; then
@@ -95,7 +95,7 @@ spec:
              memory: 32Mi
      containers:
        - name: home-assistant
-          image: ghcr.io/home-assistant/home-assistant:2026.10.1 # {"$imagepolicy": "flux-system:home-assistant"}
+          image: ghcr.io/home-assistant/home-assistant:2026.10.2 # {"$imagepolicy": "flux-system:home-assistant"}
          env:
            - name: TZ
              value: Europe/Berlin
@@ -298,8 +298,10 @@ spec:
        # force-syncs only the HA YAML config paths from origin/main of the
        # gitea repo into the working tree, then calls homeassistant.reload_all.
        # Leaves www/ (HACS-managed) and untracked runtime state (.storage,
-        # *.db, secrets.yaml) untouched. git auth uses the PAT already embedded
-        # in the PVC's remote URL; reload auth uses a dedicated long-lived token.
+        # *.db, secrets.yaml) untouched. Git and the Gitea API authenticate as
+        # ha-config-sync with the token file from home-assistant-config-sync-gitea
+        # (re-read every loop, so a rotation needs no restart); reload auth uses a
+        # dedicated long-lived token.
        # Runs as root to match HA's root-owned /config files. See config-sync.sh.
        - name: config-sync
          image: alpine/git:2.54.0@sha256:ce84fd6a057b4dc5cf5009da2dd832f1c6d096c1984bf50496cf3c256402264d
@@ -316,12 +318,23 @@ spec:
                secretKeyRef:
                  name: home-assistant-config-sync-token
                  key: token
+            - name: GITEA_URL
+              value: https://gitea.renner.uno
+            - name: GITEA_REPO
+              value: konairius/homeassistant
+            - name: GITEA_USER
+              value: ha-config-sync
+            - name: GITEA_TOKEN_FILE
+              value: /run/gitea/token
          volumeMounts:
            - name: config
              mountPath: /config
            - name: config-sync-script
              mountPath: /scripts
              readOnly: true
+            - name: config-sync-gitea
+              mountPath: /run/gitea
+              readOnly: true
          # ~1.1 GB .git (a 1 GB backup tar in history); auto-gc is disabled in
          # the script so it never repacks. fetch/checkout of small config blobs
          # peak well under this; the headroom covers index-pack on first fetch.
@@ -343,6 +356,11 @@ spec:
          configMap:
            name: ha-config-sync-script
            defaultMode: 0755
+        # Not subPath, so a rotated token lands in place.
+        - name: config-sync-gitea
+          secret:
+            secretName: home-assistant-config-sync-gitea
+            defaultMode: 0400
        - name: proxy-config
          configMap:
            name: ha-proxy-config
@@ -116,7 +116,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: ha-pg-store
+          barmanObjectName: ha-pg-store-source
          serverName: ha-pg
  postgresql:
    parameters:
@@ -1,35 +0,0 @@
---
-# Barman object store for ha-pg: base backups + continuous WAL archiving to
-# Hetzner Object Storage, same target bucket as the other CNPG clusters.
-#
-# Its own prefix. Two clusters archiving WAL to one destinationPath interleave
-# their streams and corrupt both — see the note in
-# kubernetes/apps/woodpecker/objectstore.yaml, which learned that the hard way.
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: ha-pg-store
-  namespace: home-assistant
-spec:
-  configuration:
-    destinationPath: s3://renner-uno-k8s-cnpg/ha-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  # Matches the 30d retention the other CNPG clusters use and the
-  # renner-uno-k8s-cnpg bucket's noncurrent-version expiry in
-  # opentofu/object_storage.tf, so old S3 versions don't outlive the backups
-  # that superseded them.
-  retentionPolicy: "30d"
@@ -10,6 +10,7 @@ resources:
  - vscode-ingress.yaml
  - prometheus-token-externalsecret.yaml
  - config-sync-token-externalsecret.yaml
+  - config-sync-gitea-externalsecret.yaml
  - mosquitto-bootstrap.yaml
  # Former `health` probe credential. The broker no longer reads it (the
  # probes use the cert account mosquitto-probe, REN-953); removed with its
@@ -21,26 +22,11 @@ resources:
  - mosquitto-iot-service.yaml
  - mosquitto-deployment.yaml
  - mosquitto-evcc-credentials-externalsecret.yaml
-  - shelly-manager-pvc.yaml
-  - shelly-manager-network-attachment.yaml
-  - shelly-manager-firmware-rbac.yaml
-  - shelly-ble-proxy-key-externalsecret.yaml
-  - shelly-manager-auth-externalsecret.yaml
-  - shelly-manager-llat-externalsecret.yaml
-  - shelly-manager-deployment.yaml
-  - shelly-manager-service.yaml
-  - shelly-manager-ingress.yaml
+  # shelly-manager and the mDNS relay sit on the IoT VLAN: ../home-assistant-iot.
  - esphome-pvc.yaml
  - esphome-deployment.yaml
  - esphome-service.yaml
  - esphome-ingress.yaml
-  # mDNS relay — carries IoT-VLAN announcements into HA's zeroconf listener as
-  # unicast, which is the only direction the CNI will move them. Without it HA
-  # never learns that a device's DHCP lease moved. See the header comment in
-  # mdns-relay-deployment.yaml.
-  - mdns-relay-network-attachment.yaml
-  - mdns-relay-service.yaml
-  - mdns-relay-deployment.yaml
  # Zigbee2MQTT — ZHA replacement bridge. Ships scaled to 0; the cutover
  # runbook (zigbee2mqtt-migration-runbook.md) scales it up. The MQTT
  # `zigbee2mqtt` broker user is provisioned by mosquitto-bootstrap.yaml
@@ -57,7 +43,6 @@ resources:
  # Live: recorder.db_url in the homeassistant repo points here, and the
  # long-term statistics carry their full history from 2024.
  - ha-pg-hetzner-creds-externalsecret.yaml
-  - ha-pg-objectstore.yaml
  - ha-pg-cluster.yaml
  - ha-pg-scheduled-backup.yaml
  # MQTT credential management (REN-802): the account controller manages the
@@ -66,6 +51,8 @@ resources:
  # Register: mqtt-accounts.yaml (configMapGenerator).
  - mosquitto-dynsec-test.yaml
  - mqtt-account-controller.yaml
+  # Also mounted by shelly-manager (../home-assistant-iot), which runs after this.
+  - shelly-manager-auth-externalsecret.yaml
 configMapGenerator:
  # nginx config for the reverse-proxy sidecar. Hash suffix disabled so
  # the cm name stays stable; editing proxy.conf does not auto-roll the
@@ -116,13 +103,5 @@ configMapGenerator:
    namespace: home-assistant
    files:
      - mqtt-accounts.yaml
-  # shelly-manager api-proxy sidecar config (REN-935). Hash suffix disabled
-  # (name stays stable), so editing shelly-manager-api-proxy.conf does not
-  # auto-roll the pod — restart manually with
-  # `kubectl rollout restart deploy/shelly-manager -n home-assistant`.
-  - name: shelly-manager-api-proxy
-    namespace: home-assistant
-    files:
-      - api.conf.template=shelly-manager-api-proxy.conf
 generatorOptions:
  disableNameSuffixHash: true
@@ -305,10 +305,13 @@ spec:
              - key: api-key
                path: api-key
        # Client certificate HA gets (cert-manager renews it in place; not a
-        # subPath mount, so the next loop sees the new file).
+        # subPath mount, so the next loop sees the new file). Optional: this
+        # controller creates its Certificate, so on a new cluster the Secret
+        # appears only after the controller has started.
        - name: ha-mqtt-tls
          secret:
            secretName: mqtt-home-assistant-tls
+            optional: true
        # HA long-lived token of the service user `MQTT Cert Sync`
        # (system-admin; config flows need admin). REN-1268.
        - name: ha-token
@@ -43,7 +43,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: im-pg-store
+          barmanObjectName: im-pg-store-source
          serverName: im-pg
  postgresql:
    # vchord only. The image also ships pgvecto.rs (vectors.so), but its
@@ -8,10 +8,9 @@ resources:
  - ingress.yaml
  # im-pg CNPG Postgres + library/ml-cache PVCs (moved here from the retired
  # seed-immich KS; each carries prune: disabled so ownership transferred without
-  # a teardown). This KS gains the infrastructure-cnpg-barman dep + CNPG Cluster
-  # healthCheckExprs (see clusters/homelab/immich.yaml).
+  # a teardown). This KS depends on cnpg-object-stores and health-checks the
+  # CNPG Cluster (see clusters/homelab/immich.yaml).
  - cluster.yaml
-  - objectstore.yaml
  - scheduled-backup.yaml
  - hetzner-creds-externalsecret.yaml
  - pvcs.yaml
@@ -1,33 +0,0 @@
---
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: im-pg-store
-  namespace: immich
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->immich-KS handoff (backup target).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  configuration:
-    # Offsite Hetzner Object Storage (fsn1) — replaces Garage on nas-1.
-    # No SSE: Hetzner supports only SSE-C, unusable by barman-cloud
-    # (plugin #646), so at-rest encryption is unavailable; transit is TLS.
-    destinationPath: s3://renner-uno-k8s-cnpg/im-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      # Region is required (REGION=fsn1) — without it boto3's HeadBucket
-      # (barman-cloud-check-wal-archive during bootstrap.recovery) 400s.
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  retentionPolicy: "30d"
@@ -44,6 +44,9 @@ spec:
      labels:
        app.kubernetes.io/name: llama-server
    spec:
+      # Runs only where the node patch declares the Intel iGPU.
+      nodeSelector:
+        hardware.renner.uno/intel-gpu: "true"
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
@@ -34,6 +34,9 @@ spec:
      labels:
        app.kubernetes.io/name: llama-embed
    spec:
+      # Runs only where the node patch declares the Intel iGPU.
+      nodeSelector:
+        hardware.renner.uno/intel-gpu: "true"
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
@@ -23,6 +23,9 @@ spec:
      labels:
        app.kubernetes.io/name: wiki-embed
    spec:
+      # Runs only where the node patch declares the Intel iGPU.
+      nodeSelector:
+        hardware.renner.uno/intel-gpu: "true"
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
@@ -31,7 +31,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: mx-pg-store
+          barmanObjectName: mx-pg-store-source
          serverName: mx-pg
  postgresql:
    parameters:
@@ -9,6 +9,5 @@ resources:
  # mx-pg CNPG Postgres + offsite Barman backup. The media store and signing
  # key are on synapse-data, backed up by Velero (matrix-daily).
  - cluster.yaml
-  - objectstore.yaml
  - scheduled-backup.yaml
  - hetzner-creds-externalsecret.yaml
@@ -1,30 +0,0 @@
---
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: mx-pg-store
-  namespace: matrix
-spec:
-  configuration:
-    # Offsite Hetzner Object Storage (fsn1), same bucket as the other CNPG
-    # clusters. No SSE: Hetzner supports only SSE-C, unusable by barman-cloud
-    # (plugin #646), so at-rest encryption is unavailable; transit is TLS.
-    destinationPath: s3://renner-uno-k8s-cnpg/mx-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      # Region is required (REGION=fsn1) — without it boto3's HeadBucket
-      # (barman-cloud-check-wal-archive during bootstrap.recovery) 400s.
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  retentionPolicy: "30d"
@@ -32,11 +32,9 @@ spec:
      # OTBR via OTBR's ClusterIP Service). The macvlan attachment
      # above is additive, not a replacement.
      #
-      # No nodeSelector/toleration: this pod only needs v30iot (present
-      # on all nodes), not the edge USB devices. Dropping the
-      # workload-class=pinned toleration lets the edge taint keep it off
-      # the (tiny) edge box, reserving that node for the USB-bound
-      # home-assistant + zwave-js pods.
+      # Runs where the node patch declares the IoT VLAN (ens19).
+      nodeSelector:
+        net.renner.uno/iot-vlan: "true"
      containers:
        - name: matter-server
          # Use the HAOS-published image from `ghcr.io/matter-js/...`,
@@ -1,63 +0,0 @@
---
-# Only radius needs a hand-written ServiceMonitor. The goauthentik.io operator
-# creates one per outpost and Prometheus discovers those directly, because
-# serviceMonitorSelector here is empty (see monitoring/helmrelease-prometheus.yaml).
-# Standalone copies for ldap and paperless-gate used to live here as well; they
-# duplicated the operator's and were removed.
-#
-# Radius requires extra plumbing. The radius binary listens on :9300 just
-# like ldap/proxy (hardcoded in authentik/lib/default.yml), but authentik's
-# Python operator (`providers/radius/controllers/kubernetes.py`) omits the
-# `DeploymentPort(9300, "http-metrics", "tcp", 9300)` entry from its
-# `deployment_ports` list — that's an upstream bug; the ldap controller has
-# it, radius does not. Result: the operator-managed `ak-outpost-local-radius`
-# Service exposes only UDP 1812. Add a sibling Service here that selects the
-# same pod labels and exposes 9300/TCP, then a ServiceMonitor for it.
-#
-# The operator's own `ak-outpost-local-radius` ServiceMonitor cannot cover
-# this: it selects on `app.kubernetes.io/managed-by: goauthentik.io` together
-# with `goauthentik.io/service-type: metrics`, and no Service carries both —
-# the operator's has the first, the one below has the second.
-apiVersion: v1
-kind: Service
-metadata:
-  name: ak-outpost-local-radius-metrics
-  namespace: authentik
-  labels:
-    app.kubernetes.io/managed-by: homelab
-    goauthentik.io/outpost-name: local-radius
-    goauthentik.io/outpost-type: radius
-spec:
-  type: ClusterIP
-  clusterIP: None
-  selector:
-    goauthentik.io/outpost-name: local-radius
-    goauthentik.io/outpost-type: radius
-  ports:
-    - name: http-metrics
-      port: 9300
-      targetPort: 9300
-      protocol: TCP
---
-apiVersion: monitoring.coreos.com/v1
-kind: ServiceMonitor
-metadata:
-  name: authentik-outpost-radius
-  namespace: authentik
-  labels:
-    release: kube-prometheus-stack
-spec:
-  namespaceSelector:
-    matchNames:
-      - authentik
-  selector:
-    # Pinned to the Service above. Without managed-by this would also match the
-    # operator's Service and scrape the same endpoint twice.
-    matchLabels:
-      app.kubernetes.io/managed-by: homelab
-      goauthentik.io/outpost-name: local-radius
-      goauthentik.io/outpost-type: radius
-  endpoints:
-    - port: http-metrics
-      path: /metrics
-      interval: 30s
@@ -0,0 +1,24 @@
+---
+# authentik server metrics. The chart's metrics Service stays; only its
+# ServiceMonitor is declared here (see apps/authentik/helmrelease.yaml).
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+  name: authentik-server-metrics
+  namespace: authentik
+  labels:
+    release: kube-prometheus-stack
+spec:
+  namespaceSelector:
+    matchNames:
+      - authentik
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: authentik
+      app.kubernetes.io/instance: authentik
+      app.kubernetes.io/component: server-metrics
+  endpoints:
+    - port: metrics
+      path: /metrics
+      interval: 30s
+      scrapeTimeout: 3s
@@ -10,6 +10,9 @@ resources:
  - prometheusrule-cilium.yaml
  - prometheusrule-disk-wear.yaml
  - prometheusrule-hetzner-backup.yaml
+  # Replaces the chart's KubeJobFailed/KubeContainerWaiting (disabled in
+  # apps/monitoring/helmrelease-prometheus.yaml).
+  - prometheusrule-jobs.yaml
  - prometheusrule-loki.yaml
  - prometheusrule-mariadb-backup.yaml
  - prometheusrule-netbird-availability.yaml
@@ -49,7 +52,7 @@ resources:
  # cannot live beside the Velero HelmRelease.
  - velero-podmonitor.yaml
  - velero-servicemonitor.yaml
-  - authentik-outpost-servicemonitors.yaml
+  - authentik-servicemonitor.yaml
  # Rook's exporter/mgr monitors: the operator aborts its node-daemon reconcile
  # when it cannot create these, which held the CephCluster in Progressing and
  # deadlocked the whole apps layer. See the file for the cycle.
@@ -269,9 +269,9 @@ spec:
        # per the app's own test (shelly-manager repo,
        # AuthenticationTests.Health_IsUnauthenticated); it is also the pod's
        # kubelet liveness/readiness path
-        # (../home-assistant/shelly-manager-deployment.yaml). AllowedHosts is
+        # (../home-assistant-iot/shelly-manager-deployment.yaml). AllowedHosts is
        # "*", so the cluster-local Host header is accepted. Service :80 ->
-        # container :8080 (../home-assistant/shelly-manager-service.yaml).
+        # container :8080 (../home-assistant-iot/shelly-manager-service.yaml).
        #
        # NO CiliumNetworkPolicy change: the home-assistant default-deny
        # admits the whole monitoring namespace on every port
@@ -0,0 +1,61 @@
+apiVersion: monitoring.coreos.com/v1
+kind: PrometheusRule
+metadata:
+  name: jobs
+  namespace: monitoring
+  labels:
+    # kube-prometheus-stack's Prometheus selects on this label.
+    release: kube-prometheus-stack
+spec:
+  groups:
+    - name: jobs.rules
+      rules:
+        # Maps each Job to the series of runs it belongs to: its owning
+        # CronJob, or its Velero repository for kopia maintenance Jobs.
+        - record: job_name:kube_job_series:info
+          expr: |
+            max by (namespace, job_name, series) (
+              label_replace(kube_job_owner{job="kube-state-metrics", owner_kind="CronJob"}, "series", "$1", "owner_name", "(.+)")
+              or
+              label_replace(kube_job_labels{job="kube-state-metrics", label_velero_io_repo_name!=""}, "series", "$1", "label_velero_io_repo_name", "(.+)")
+            )
+
+        - alert: KubeJobFailed
+          # A failed Job resolves once a later run of the same series succeeds.
+          expr: |
+            kube_job_failed{job="kube-state-metrics", condition="true"} > 0
+            unless on(namespace, job_name)
+            (
+              (
+                kube_job_status_start_time{job="kube-state-metrics"}
+                * on(namespace, job_name) group_left(series)
+                job_name:kube_job_series:info
+              )
+              < on(namespace, series) group_left()
+              max by (namespace, series) (
+                kube_job_status_completion_time{job="kube-state-metrics"}
+                * on(namespace, job_name) group_left(series)
+                job_name:kube_job_series:info
+              )
+            )
+          for: 15m
+          labels:
+            severity: warning
+          annotations:
+            summary: Job failed to complete.
+            description: "Job {{ $labels.namespace }}/{{ $labels.job_name }} failed and no later run of the same CronJob or Velero repository has succeeded."
+            runbook_url: https://runbooks.prometheus-operator.dev/runbooks/kubernetes/kubejobfailed
+
+        - alert: KubeContainerWaiting
+          # Containers of Failed/Succeeded pods never start; KubeJobFailed covers those.
+          expr: |
+            kube_pod_container_status_waiting_reason{job="kube-state-metrics", reason!="CrashLoopBackOff"} > 0
+            unless on(namespace, pod)
+            (kube_pod_status_phase{job="kube-state-metrics", phase=~"Failed|Succeeded"} == 1)
+          for: 1h
+          labels:
+            severity: warning
+          annotations:
+            summary: Pod container waiting longer than 1 hour
+            description: 'pod/{{ $labels.pod }} in namespace {{ $labels.namespace }} on container {{ $labels.container }} has been in waiting state for longer than 1 hour. (reason: "{{ $labels.reason }}")'
+            runbook_url: https://runbooks.prometheus-operator.dev/runbooks/kubernetes/kubecontainerwaiting
@@ -317,9 +317,7 @@ spec:
            - matchers:
                - alertname = "InfoInhibitor"
              receiver: 'null'
-            # Flux notification-controller posts info-severity events
-            # here (e.g. image-automation commits). Keep them visible
-            # but don't repeat-spam every 12h on the same event.
+            # Flux notification-controller error events (flux-failures Alert).
            - matchers:
                - source = "flux"
              receiver: email
@@ -369,6 +367,10 @@ spec:
        limits:
          memory: 256Mi

+      # Groups Velero maintenance Jobs per repository in prometheusrule-jobs.yaml.
+      metricLabelsAllowlist:
+        - jobs=[velero.io/repo-name]
+
      # --- Flux per-object readiness (REN-102) ---------------------------------
      #
      # WHY THIS IS HERE AND NOT ON THE FLUX CONTROLLERS. `gotk_reconcile_condition`
@@ -703,3 +705,9 @@ spec:
      enabled: false
    kubeProxy:
      enabled: false
+
+    # Replaced by monitoring-rules/prometheusrule-jobs.yaml.
+    defaultRules:
+      disabled:
+        KubeJobFailed: true
+        KubeContainerWaiting: true
@@ -25,6 +25,8 @@ spec:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
+      nodeSelector:
+        hardware.renner.uno/intel-gpu: "true"
      securityContext:
        seccompProfile:
          type: RuntimeDefault
@@ -33,12 +33,9 @@ spec:
        k8s.v1.cni.cncf.io/networks: music-assistant-iot
    spec:
      enableServiceLinks: false
-      # No nodeSelector/toleration: MA only needs a node on v30iot (all
-      # of them) for audio-sync L2, not the edge USB devices. It's the
-      # heaviest of the formerly edge-pinned pods (2Gi limit), so
-      # dropping the workload-class=pinned toleration — which lets the
-      # edge taint keep it off the tiny edge box — is the main capacity
-      # win for this step.
+      # Runs where the node patch declares the IoT VLAN (ens19).
+      nodeSelector:
+        net.renner.uno/iot-vlan: "true"
      initContainers:
        # MA advertises a stored publish_ip to players (Sendspin / Snapcast /
        # SlimProto) and binds its stream + Sendspin servers to a stored
@@ -55,7 +52,7 @@ spec:
        # stdlib only; Flux keeps the tag in lockstep via the shared image
        # policy) — no extra dependency.
        - name: reconcile-publish-ip
-          image: ghcr.io/music-assistant/server:2.10.6 # {"$imagepolicy": "flux-system:music-assistant"}
+          image: ghcr.io/music-assistant/server:2.10.7 # {"$imagepolicy": "flux-system:music-assistant"}
          command: ["/app/venv/bin/python", "/scripts/reconcile.py"]
          volumeMounts:
            - name: data
@@ -65,7 +62,7 @@ spec:
              readOnly: true
      containers:
        - name: music-assistant
-          image: ghcr.io/music-assistant/server:2.10.6 # {"$imagepolicy": "flux-system:music-assistant"}
+          image: ghcr.io/music-assistant/server:2.10.7 # {"$imagepolicy": "flux-system:music-assistant"}
          env:
            - name: LOG_LEVEL
              value: info
@@ -30,11 +30,10 @@ spec:
        # the IoT VLAN for mDNS/SRP advertisements and RA listening.
        k8s.v1.cni.cncf.io/networks: otbr-iot
    spec:
-      # No nodeSelector/toleration: OTBR only needs v30iot L2 presence
-      # (macvlan master: ens19, present on every node), not the edge USB
-      # devices, and its Thread RCP is reached over the network
-      # (slzb-thread.renner.uno). Dropping the workload-class=pinned
-      # toleration lets the edge taint keep it off the tiny edge box.
+      # Runs where the node patch declares the IoT VLAN (ens19). Its Thread
+      # RCP is reached over the network (slzb-thread.renner.uno).
+      nodeSelector:
+        net.renner.uno/iot-vlan: "true"
      containers:
        # The Thread RCP is a network-attached radio (Serial-over-IP), so the
        # spinel transport needs a TCP-to-PTY bridge. Two obvious approaches
@@ -39,7 +39,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: pprl-pg-store
+          barmanObjectName: pprl-pg-store-source
          serverName: pprl-pg
  postgresql:
    parameters:
@@ -43,7 +43,7 @@ spec:
              mountPath: /consume
      containers:
        - name: vsftpd
-          image: gitea.renner.uno/k.renner/vsftpd:build.1789630783 # {"$imagepolicy": "flux-system:vsftpd"}
+          image: gitea.renner.uno/konairius/vsftpd:build.1792310564 # {"$imagepolicy": "flux-system:vsftpd"}
          ports:
            - name: ftp-ctrl
              containerPort: 21
@@ -14,10 +14,9 @@ resources:
  - network-policy.yaml
  # pprl-pg CNPG Postgres + data/media/consume/redis PVCs (moved here from the
  # retired seed-paperless KS; each carries prune: disabled so ownership
-  # transferred without a teardown). This KS gains the infrastructure-cnpg-barman
-  # dep + CNPG Cluster healthCheckExprs (see clusters/homelab/paperless.yaml).
+  # transferred without a teardown). This KS depends on cnpg-object-stores and
+  # health-checks the CNPG Cluster (see clusters/homelab/paperless.yaml).
  - cluster.yaml
-  - objectstore.yaml
  - scheduled-backup.yaml
  - hetzner-creds-externalsecret.yaml
  - pvcs.yaml
@@ -1,35 +0,0 @@
---
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: pprl-pg-store
-  namespace: paperless
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->paperless-KS handoff (backup target).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  configuration:
-    # Offsite Hetzner Object Storage (fsn1) — replaces local Garage on
-    # nas-1 so paperless backups survive nas-1 being powered off. barman
-    # uses boto3 default (auto) addressing; Hetzner (Ceph RGW) accepts it.
-    destinationPath: s3://renner-uno-k8s-cnpg/pprl-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    # No `encryption: AES256` (SSE-S3): Hetzner Object Storage supports
-    # only SSE-C, which the barman-cloud plugin can't use (cnpg
-    # plugin-barman-cloud #646). At-rest encryption is therefore not
-    # available here; transit is TLS and the bucket is private.
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  retentionPolicy: "30d"
@@ -4,7 +4,7 @@
 # This is the configuration of the RUNNER only: where Gitea is, and which
 # repositories to process. What Renovate does INSIDE a repository — schedule,
 # grouping, commit titles, digest pinning — lives in the shared preset repository
-# `k.renner/renovate-config`, which each repository's renovate.json extends. Change
+# `konairius/renovate-config`, which each repository's renovate.json extends. Change
 # update policy there, not here.
 #
 #   autodiscover + requireConfig=required + onboarding=false
@@ -2,7 +2,7 @@
 # Renovate runner (REN-216).
 #
 # RUNS DAILY, BUT OPENS ROUTINE PULL REQUESTS ON MONDAY ONLY. The weekly rhythm
-# is enforced by the `schedule` in the shared preset (k.renner/renovate-config),
+# is enforced by the `schedule` in the shared preset (konairius/renovate-config),
 # not by this cron line. The daily run exists for one reason: a security update
 # (`vulnerabilityAlerts`, which the preset leaves unscheduled) must not wait up
 # to six days. On Tuesday to Sunday a run finds nothing in schedule, opens and
@@ -32,18 +32,40 @@ spec:
          type: RuntimeDefault
      containers:
        - name: review-bot
-          image: gitea.renner.uno/gitea_admin/review-bot:2026-10-16-0620 # {"$imagepolicy": "flux-system:review-bot"}
+          image: gitea.renner.uno/gitea_admin/review-bot:2026-10-18-0706 # {"$imagepolicy": "flux-system:review-bot"}
          env:
            - name: REPOS
-              value: k.renner/homelab,k.renner/homeassistant,k.renner/authentik-samba-bridge,konairius/shelly-manager
+              value: k.renner/homelab,konairius/homeassistant,konairius/authentik-samba-bridge,konairius/shelly-manager
            - name: GITEA_URL
              value: https://gitea.renner.uno
            - name: AGENT_NAME
              value: pr-review
-            - name: AGENT_MODEL
-              value: mistral-large-4-0
            - name: CONNECTOR_ID
              value: 01a12adf-cdc3-7562-b32b-b1fa96be244c
+            # The first model is the default; a backend without its keys is off.
+            - name: MODELS
+              value: |
+                mistral:mistral-large-4-0 = Mistral Large 4. Solid on routine changes of small to medium size.
+                anthropic:claude-haiku-5-5 = Claude Haiku 5.5. Cheapest and fastest; only for trivial changes such as documentation, comments or version bumps.
+                anthropic:claude-sonnet-5-5 = Claude Sonnet 5.5. Fast and capable; good for most code and configuration changes.
+                anthropic:claude-opus-5-5 = Claude Opus 5.5. The strongest reviewer; for large or cross-cutting changes and anything touching security, secrets, network policy or data.
+            - name: SELECTOR
+              value: typesafe
+            - name: ANTHROPIC_API_KEY
+              valueFrom:
+                secretKeyRef:
+                  name: review-bot-secrets
+                  key: ANTHROPIC_API_KEY
+            - name: MCP_TOKEN
+              valueFrom:
+                secretKeyRef:
+                  name: review-bot-secrets
+                  key: MCP_TOKEN
+            - name: TYPESAFE_API_KEY
+              valueFrom:
+                secretKeyRef:
+                  name: review-bot-secrets
+                  key: TYPESAFE_API_KEY
            - name: WEBHOOK_SECRET
              valueFrom:
                secretKeyRef:
@@ -17,10 +17,23 @@ spec:
        property: webhook-secret
    - secretKey: MISTRAL_API_KEY
      remoteRef:
-        key: apps/wiki
-        property: minstral-token
-    # The review-bot token, rotated quarterly by the review-bot-secret-rotate CronJob.
+        key: apps/review-bot
+        property: minstral-api-key
+    - secretKey: ANTHROPIC_API_KEY
+      remoteRef:
+        key: apps/review-bot
+        property: antropic-api-key
+    - secretKey: TYPESAFE_API_KEY
+      remoteRef:
+        key: apps/review-bot
+        property: typesafe-api-key
+    # The review-bot tokens, rotated quarterly by the review-bot-secret-rotate CronJob; MCP_TOKEN is
+    # the read-only one for the Gitea MCP server.
    - secretKey: REVIEW_TOKEN
      remoteRef:
        key: infrastructure/review-bot
        property: token
+    - secretKey: MCP_TOKEN
+      remoteRef:
+        key: infrastructure/review-bot
+        property: mcp_token
@@ -36,7 +36,7 @@ spec:
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
-          barmanObjectName: tr-pg-store
+          barmanObjectName: tr-pg-store-source
          serverName: tr-pg
  postgresql:
    parameters:
@@ -18,6 +18,5 @@ resources:
  # tr-pg CNPG Postgres + offsite Barman backup. Note this cluster runs
  # PostgreSQL 18, not the repo-standard 16 — see the comment in cluster.yaml.
  - cluster.yaml
-  - objectstore.yaml
  - scheduled-backup.yaml
  - hetzner-creds-externalsecret.yaml
@@ -1,30 +0,0 @@
---
-apiVersion: barmancloud.cnpg.io/v1
-kind: ObjectStore
-metadata:
-  name: tr-pg-store
-  namespace: trmnl
-spec:
-  configuration:
-    # Offsite Hetzner Object Storage (fsn1), same bucket as the other CNPG
-    # clusters. No SSE: Hetzner supports only SSE-C, unusable by barman-cloud
-    # (plugin #646), so at-rest encryption is unavailable; transit is TLS.
-    destinationPath: s3://renner-uno-k8s-cnpg/tr-pg
-    endpointURL: https://fsn1.your-objectstorage.com
-    s3Credentials:
-      accessKeyId:
-        name: hetzner-s3-creds
-        key: ACCESS_KEY_ID
-      secretAccessKey:
-        name: hetzner-s3-creds
-        key: ACCESS_SECRET_KEY
-      # Region is required (REGION=fsn1) — without it boto3's HeadBucket
-      # (barman-cloud-check-wal-archive during bootstrap.recovery) 400s.
-      region:
-        name: hetzner-s3-creds
-        key: REGION
-    wal:
-      compression: gzip
-    data:
-      compression: gzip
-  retentionPolicy: "30d"
@@ -39,6 +39,10 @@ spec:
      labels:
        app.kubernetes.io/name: wiki
    spec:
+      # Its embedding backend (wiki-embed) needs the Intel iGPU; without it
+      # the wiki has nothing to serve, so it runs where the iGPU is declared.
+      nodeSelector:
+        hardware.renner.uno/intel-gpu: "true"
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
@@ -63,7 +67,7 @@ spec:
            - name: Wiki__NoteStore__Gitea__BaseUrl
              value: https://gitea.renner.uno
            - name: Wiki__NoteStore__Gitea__Repository
-              value: k.renner/notes
+              value: konairius/notes
            - name: Wiki__NoteStore__Gitea__Branch
              value: main
            - name: Wiki__Embeddings__Models__bge-m3__Url
@@ -31,9 +31,8 @@ resources:
  # not here: it must exist before the `infrastructure-crds` KS applies the
  # namespace's CiliumNetworkPolicies, and this KS runs after both of those.
  #
-  # This KS depends on infrastructure-cnpg-barman for the barman plugin behind
-  # the ObjectStore and ScheduledBackup.
+  # This KS depends on cnpg-object-stores for the ObjectStores its Cluster and
+  # ScheduledBackup name.
  - hetzner-creds-externalsecret.yaml
-  - objectstore.yaml
  - cluster.yaml
  - scheduled-backup.yaml
@@ -33,6 +33,10 @@ spec:
            "k8s:io.kubernetes.pod.namespace": openbao
            app.kubernetes.io/component: secret-rotator
            app.kubernetes.io/name: claude-oauth
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": openbao
+            app.kubernetes.io/component: secret-rotator
+            app.kubernetes.io/name: registry-bot
      toPorts:
        - ports:
            - port: "8000"
@@ -17,6 +17,7 @@ spec:
  # woodpecker migrated) — secrets come from OpenBao via ESO
  # (MIGRATION-sops-openbao.md).
  dependsOn:
+    - name: restore-apps
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -22,6 +22,7 @@ spec:
    secretRef:
      name: sops-age
  dependsOn:
+    - name: restore-audiobookshelf
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -20,10 +20,12 @@ spec:
  # from OpenBao via ESO (MIGRATION-sops-openbao.md). This was the LAST
  # sops consumer; phase 4 (age-key retirement) may proceed after soak.
  dependsOn:
+    - name: restore-authentik
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
-    - name: infrastructure-cnpg-barman
+    - name: cnpg-object-stores # the ObjectStores its Cluster names
+    - name: gitea # server, LDAP outpost and gate-sync images are in Gitea's registry
  healthCheckExprs:
    - apiVersion: postgresql.cnpg.io/v1
      kind: Cluster
@@ -0,0 +1,27 @@
+# The CNPG ObjectStores. Their paths come from the cnpg-paths ConfigMap, which
+# bootstrap.sh writes once per cluster incarnation and never replaces:
+#   CNPG_<X>_SOURCE   the bucket prefix holding <x>'s newest base backup
+#   CNPG_<X>_ARCHIVE  a new, empty prefix <x>-g<timestamp>
+# Not optional: without it every path renders empty.
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: cnpg-object-stores
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 5m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/cnpg-object-stores
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-cnpg-barman
+  postBuild:
+    substituteFrom:
+      - kind: ConfigMap
+        name: cnpg-paths
@@ -19,3 +19,5 @@ spec:
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
+    # mqtt-account-controller there delivers mqtt-evcc-client-tls; mosquitto is the broker.
+    - name: home-assistant
@@ -16,3 +16,4 @@ spec:
  dependsOn:
    - name: infrastructure
    - name: infrastructure-crds
+    - name: gitea # serves Gitea's API
@@ -14,7 +14,14 @@ spec:
  path: ./kubernetes/apps/gitea
  prune: true
  wait: true
+  # The claim's bound volume differs per cluster (apps/gitea/pvc.yaml).
+  ignore:
+    - paths: ["/spec/volumeName"]
+      target:
+        kind: PersistentVolumeClaim
+        name: data-gitea-0
  dependsOn:
+    - name: restore-gitea
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -4,43 +4,28 @@ metadata:
  name: home-assistant
  namespace: flux-system
 spec:
-  # Seed Job collapsed into the HA pod's `seed` initContainer so the
-  # backup tarball + .HA_RESTORE manifest staging happens in the same
-  # pod as HA Core (no Multi-Attach race against the RWO Ceph-RBD
-  # PVC if production grows to multiple edge nodes). HA Core still
-  # does the actual restore from the staged manifest on its boot.
-  # Timeout has to absorb the worst-case 3h wait for the HAOS backup
-  # to appear in Garage plus the in-pod download + HA's native restore.
+  # The slowest part on a cold start is ha-pg recovering from barman (base
+  # backup ~1.7 GiB compressed, then WAL replay); the config PVC is restored
+  # beforehand by restore-home-assistant.
  interval: 10m
  retryInterval: 1m
-  timeout: 4h
+  timeout: 30m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./kubernetes/apps/home-assistant
  prune: true
-  # Same TBD-USB caveat for the stromzaehler hostPath. Manifests apply;
-  # HA pod may CrashLoop until the USB is present — acceptable during canary.
-  wait: false
+  wait: true
  # decryption block dropped 2026-07-13: path is sops-free — secrets come
  # from OpenBao via ESO (MIGRATION-sops-openbao.md).
  dependsOn:
+    - name: restore-home-assistant
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
-    # ha-pg-objectstore.yaml declares an ObjectStore, whose CRD comes from the
-    # CNPG Barman plugin in infrastructure-cnpg-barman. Without this edge the
-    # kind is unknown when this path is first applied, and a server-side
-    # dry-run rejects the ENTIRE set over the one object it cannot recognise:
-    #
-    #   ObjectStore/home-assistant/ha-pg-store dry-run failed:
-    #   no matches for kind "ObjectStore" in version ...
-    #
-    # Every other ObjectStore user — authentik, immich, paperless, trmnl,
-    # woodpecker — already declares it. This was the only one that did not, and
-    # it took speech-to-phrase, zone-configurator and matter-server down with
-    # it, since all three wait on home-assistant.
-    - name: infrastructure-cnpg-barman
+    - name: cnpg-object-stores # the ObjectStores its Cluster names
+    - name: gitea # mqtt-account-controller's image is in Gitea's registry
+    - name: influxdb # HA's InfluxDB integration writes there
 ---
 apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
@@ -58,10 +43,35 @@ spec:
  prune: true
  wait: true
  dependsOn:
+    - name: restore-home-assistant
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
 ---
+# shelly-manager and the mDNS relay: home-assistant's IoT-VLAN workloads.
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: home-assistant-iot
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 10m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/apps/home-assistant-iot
+  prune: true
+  wait: true
+  dependsOn:
+    - name: restore-home-assistant # shelly-manager's PVC
+    - name: infrastructure
+    - name: infrastructure-crds
+    - name: infrastructure-ceph-cluster
+    - name: gitea # shelly-manager's image is in Gitea's registry
+    - name: home-assistant # both serve HA: its API, its zeroconf listener
+---
 apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
 metadata:
@@ -76,10 +86,13 @@ spec:
    name: flux-system
  path: ./kubernetes/apps/otbr
  prune: true
-  wait: false
+  # Not in use.
+  suspend: true
+  wait: true
  # decryption block dropped 2026-07-13: path is sops-free — secrets come
  # from OpenBao via ESO (MIGRATION-sops-openbao.md).
  dependsOn:
+    - name: restore-home-assistant
    - name: infrastructure
    - name: infrastructure-crds
 ---
@@ -120,6 +133,7 @@ spec:
  # First boot downloads the Whisper model (a few hundred MB) — give it room.
  wait: true
  dependsOn:
+    - name: restore-home-assistant
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -20,10 +20,11 @@ spec:
  # decryption block dropped 2026-07-13: path is sops-free — secrets come
  # from OpenBao via ESO (MIGRATION-sops-openbao.md).
  dependsOn:
+    - name: restore-immich
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
-    - name: infrastructure-cnpg-barman
+    - name: cnpg-object-stores # the ObjectStores its Cluster names
  healthCheckExprs:
    - apiVersion: postgresql.cnpg.io/v1
      kind: Cluster
@@ -25,6 +25,7 @@ spec:
  # boilerplate from the monolithic seed KS — InfluxDB has no CNPG cluster, only
  # a chart-provisioned ceph-block PVC, so ceph is the only storage dep needed.
  dependsOn:
+    - name: restore-influxdb
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -0,0 +1,19 @@
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: infrastructure-inhouse
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 2m
+  timeout: 10m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure-inhouse
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-crds
+    - name: gitea # its images are in Gitea's registry
@@ -0,0 +1,98 @@
+# Infrastructure services that consume Secrets from OpenBao. Each carries its
+# ExternalSecrets and depends on infrastructure-crds, where the openbao
+# ClusterSecretStore turns Ready only once OpenBao is unsealed, so the
+# HelmRelease never installs before its Secret exists. One Kustomization each:
+# a broken service holds back nothing but itself (velero: the restore chain).
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: crowdsec
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 10m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure/crowdsec
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-crds
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: external-dns-unifi
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 5m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure/external-dns-unifi
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-crds
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: netbird-ingress
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 10m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure/netbird-ingress
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-crds
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: velero
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 15m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure/velero
+  prune: true
+  wait: true
+  dependsOn:
+    - name: infrastructure
+    - name: infrastructure-crds
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: velero-schedules
+  namespace: flux-system
+spec:
+  interval: 10m
+  retryInterval: 1m
+  timeout: 5m
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  path: ./kubernetes/infrastructure/velero-schedules
+  prune: true
+  wait: true
+  dependsOn:
+    - name: velero # the velero.io CRDs
@@ -40,6 +40,13 @@ spec:
      kind: HelmRelease
      name: openbao # the ESO backend ExternalSecrets resolve against
      namespace: openbao
+    # Ready only when every replica is unsealed (readiness probe: bao status).
+    # The HelmRelease is Ready as soon as the chart is installed; the
+    # ClusterSecretStore in infrastructure-crds must not come up before.
+    - apiVersion: apps/v1
+      kind: StatefulSet
+      name: openbao
+      namespace: openbao
    - apiVersion: helm.toolkit.fluxcd.io/v2
      kind: HelmRelease
      name: rook-ceph-operator # storage — apps mount PVCs
@@ -17,10 +17,11 @@ spec:
  prune: true
  wait: true
  dependsOn:
+    - name: restore-matrix
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
-    - name: infrastructure-cnpg-barman
+    - name: cnpg-object-stores # the ObjectStores its Cluster names
  healthCheckExprs:
    - apiVersion: postgresql.cnpg.io/v1
      kind: Cluster
@@ -46,6 +46,7 @@ spec:
  # from OpenBao via ESO (MIGRATION-sops-openbao.md).
  dependsOn:
    - name: grafana-db
+    - name: influxdb # its Job writes the grafana-influxdb-token Secret Grafana mounts
 ---
 apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
@@ -22,6 +22,7 @@ spec:
    secretRef:
      name: sops-age
  dependsOn:
+    - name: restore-music-assistant
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -14,6 +14,7 @@ spec:
  prune: true
  wait: true
  dependsOn:
+    - name: restore-navidrome
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
@@ -20,10 +20,12 @@ spec:
  # decryption block dropped 2026-07-13: path is sops-free — secrets come
  # from OpenBao via ESO (MIGRATION-sops-openbao.md).
  dependsOn:
+    - name: restore-paperless
    - name: infrastructure
    - name: infrastructure-crds
    - name: infrastructure-ceph-cluster
-    - name: infrastructure-cnpg-barman
+    - name: cnpg-object-stores # the ObjectStores its Cluster names
+    - name: gitea # ftp-scanner (vsftpd) image is in Gitea's registry
  healthCheckExprs:
    - apiVersion: postgresql.cnpg.io/v1
      kind: Cluster
@@ -35,3 +35,4 @@ spec:
    # The `openbao` ClusterSecretStore, including the `renovate` entry in its
    # conditions.namespaces allowlist.
    - name: infrastructure-crds
+    - name: gitea # the platform it runs against (git.renner.uno)
--- a/Show More
+++ b/Show More