Pins the image from Wiki PR #4 (read API, MudBlazor pages). Adds the ExternalSecret wiki-typesafe (OpenBao apps/ai/wiki-typesafe, field api_key, stored) as Wiki__Judges__Models__typesafe__ApiKey, which the ask phase (Wiki PR #5) reads; until that image is deployed the variable is unused. TypeSafe is reached via the namespace's world egress, no policy change.
Pins the image from Wiki PR #4 (read API, MudBlazor pages). Adds the ExternalSecret `wiki-typesafe` (OpenBao `apps/ai/wiki-typesafe`, field `api_key`, stored) as `Wiki__Judges__Models__typesafe__ApiKey`, which the ask phase (Wiki PR #5) reads; until that image is deployed the variable is unused. TypeSafe is reached via the namespace's world egress, no policy change.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
🤖Automated review — model CLI default (complexity: complex), commit edc07f254321e033ab8222b95caff3455fc9f54f.
Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.
Summary
Bumps the wiki deployment image to build.1790257176 and adds a new wiki-typesafe ExternalSecret that injects Wiki__Judges__Models__typesafe__ApiKey from OpenBao (apps/ai/wiki-typesafe/api_key). Small, well-scoped change that follows the existing conventions in this app exactly; I verified the networking claim in the PR description and it holds up.
No blocking issues.
🟡 Suggestions
kubernetes/apps/wiki/externalsecrets.yaml:45: the new wiki-typesafe ExternalSecret is env-injected via envFrom on the Deployment — like the other two secrets in this file, a key rotation in OpenBao won't take effect until the pod restarts (ESO updates the underlying Secret, but envFrom doesn't hot-reload). This matches the existing wiki-gitea/wiki-api-keys pattern, so it's consistent, not a regression — just flagging since it's a new credential path.
Tests
None expected or needed — this is a GitOps manifest change (image pin + secret wiring), consistent with how the sibling image bumps and ExternalSecrets in this repo are handled without tests.
Verification notes
Confirmed the PR body's claim that "TypeSafe is reached via the namespace's world egress, no policy change" is accurate: kubernetes/infrastructure/network-policies/ai-ns.yaml grants the ai namespace toEntities: [host, remote-node, world] egress, which already covers the new outbound call from the wiki pod — no CiliumNetworkPolicy change was needed or made.
The new ExternalSecret (kubernetes/apps/wiki/externalsecrets.yaml:44-62) matches the shape, namespace (ai), secretStoreRef (ClusterSecretStore/openbao), and naming conventions of the two existing ExternalSecrets in the same file (wiki-gitea, wiki-api-keys).
The Deployment's new envFrom entry (kubernetes/apps/wiki/deployment.yaml:80-81) correctly references the new secret's target.name: wiki-typesafe.
No kustomization.yaml change was needed since both edited files were already tracked there.
Recommendation
Looks reasonable — no blocking issues; comment above is optional.
🤖 **Automated review** — model `CLI default` (complexity: complex), commit `edc07f254321e033ab8222b95caff3455fc9f54f`.
> Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review.
---
## Summary
Bumps the `wiki` deployment image to `build.1790257176` and adds a new `wiki-typesafe` ExternalSecret that injects `Wiki__Judges__Models__typesafe__ApiKey` from OpenBao (`apps/ai/wiki-typesafe`/`api_key`). Small, well-scoped change that follows the existing conventions in this app exactly; I verified the networking claim in the PR description and it holds up.
No blocking issues.
## 🟡 Suggestions
- `kubernetes/apps/wiki/externalsecrets.yaml:45`: the new `wiki-typesafe` ExternalSecret is env-injected via `envFrom` on the Deployment — like the other two secrets in this file, a key rotation in OpenBao won't take effect until the pod restarts (ESO updates the underlying `Secret`, but `envFrom` doesn't hot-reload). This matches the existing `wiki-gitea`/`wiki-api-keys` pattern, so it's consistent, not a regression — just flagging since it's a new credential path.
## Tests
None expected or needed — this is a GitOps manifest change (image pin + secret wiring), consistent with how the sibling image bumps and ExternalSecrets in this repo are handled without tests.
## Verification notes
- Confirmed the PR body's claim that "TypeSafe is reached via the namespace's world egress, no policy change" is accurate: `kubernetes/infrastructure/network-policies/ai-ns.yaml` grants the `ai` namespace `toEntities: [host, remote-node, world]` egress, which already covers the new outbound call from the `wiki` pod — no CiliumNetworkPolicy change was needed or made.
- The new ExternalSecret (`kubernetes/apps/wiki/externalsecrets.yaml:44-62`) matches the shape, namespace (`ai`), `secretStoreRef` (`ClusterSecretStore/openbao`), and naming conventions of the two existing ExternalSecrets in the same file (`wiki-gitea`, `wiki-api-keys`).
- The Deployment's new `envFrom` entry (`kubernetes/apps/wiki/deployment.yaml:80-81`) correctly references the new secret's `target.name: wiki-typesafe`.
- No `kustomization.yaml` change was needed since both edited files were already tracked there.
## Recommendation
Looks reasonable — no blocking issues; comment above is optional.
<!-- pr-review:sha=edc07f254321e033ab8222b95caff3455fc9f54f -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Pins the image from Wiki PR #4 (read API, MudBlazor pages). Adds the ExternalSecret
wiki-typesafe(OpenBaoapps/ai/wiki-typesafe, fieldapi_key, stored) asWiki__Judges__Models__typesafe__ApiKey, which the ask phase (Wiki PR #5) reads; until that image is deployed the variable is unused. TypeSafe is reached via the namespace's world egress, no policy change.🤖 Generated with Claude Code
🤖 Automated review — model
CLI default(complexity: complex), commitedc07f254321e033ab8222b95caff3455fc9f54f.Summary
Bumps the
wikideployment image tobuild.1790257176and adds a newwiki-typesafeExternalSecret that injectsWiki__Judges__Models__typesafe__ApiKeyfrom OpenBao (apps/ai/wiki-typesafe/api_key). Small, well-scoped change that follows the existing conventions in this app exactly; I verified the networking claim in the PR description and it holds up.No blocking issues.
🟡 Suggestions
kubernetes/apps/wiki/externalsecrets.yaml:45: the newwiki-typesafeExternalSecret is env-injected viaenvFromon the Deployment — like the other two secrets in this file, a key rotation in OpenBao won't take effect until the pod restarts (ESO updates the underlyingSecret, butenvFromdoesn't hot-reload). This matches the existingwiki-gitea/wiki-api-keyspattern, so it's consistent, not a regression — just flagging since it's a new credential path.Tests
None expected or needed — this is a GitOps manifest change (image pin + secret wiring), consistent with how the sibling image bumps and ExternalSecrets in this repo are handled without tests.
Verification notes
kubernetes/infrastructure/network-policies/ai-ns.yamlgrants theainamespacetoEntities: [host, remote-node, world]egress, which already covers the new outbound call from thewikipod — no CiliumNetworkPolicy change was needed or made.kubernetes/apps/wiki/externalsecrets.yaml:44-62) matches the shape, namespace (ai),secretStoreRef(ClusterSecretStore/openbao), and naming conventions of the two existing ExternalSecrets in the same file (wiki-gitea,wiki-api-keys).envFromentry (kubernetes/apps/wiki/deployment.yaml:80-81) correctly references the new secret'starget.name: wiki-typesafe.kustomization.yamlchange was needed since both edited files were already tracked there.Recommendation
Looks reasonable — no blocking issues; comment above is optional.