Review: [sprint:3] NetworkPolicy: paldocs->Keycloak (r2)

Verdict: READY

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- related to paldocs #26, hard dependency documented
• [x] Repo -- ldraney/pal-e-platform
• [x] User Story -- "As the paldocs Rails app I want network access to Keycloak..."
• [x] Context -- explains default-deny ingress, current allowlist, landscaping-assistant precedent
• [x] File Targets -- terraform/network-policies.tf identified, exclusions listed
• [x] Feature Flag -- "none" (correct for infra change)
• [x] Acceptance Criteria -- 3 items
• [x] Test Expectations -- kubectl exec curl test + tofu plan verification
• [x] Constraints -- references existing pattern and PR #413 precedent
• [x] Checklist -- standard 3-item checklist
• [x] Related -- project reference present

Traceability

• [x] story:auth label -- story-paldocs-auth (role-based access control via Keycloak)
• [x] story note verified -- found in project-paldocs user-stories section
• [x] arch:k8s label -- Kubernetes infrastructure
• [x] arch note verified -- arch-k8s note exists (id: 2039, type: architecture, status: active, project: paldocs). Title: "Kubernetes: paldocs (k3s, Kustomize, NetworkPolicies, CNPG)". Contains diagram, components table, key decisions (including: "Default-deny network policies... Must be added to keycloak allowlist for auth"), and related links. Previous blocker resolved.
• [x] Forgejo issue -- ldraney/pal-e-platform#491, state: open

File Targets

• [x] terraform/network-policies.tf -- verified: file exists at ~/pal-e-platform/terraform/network-policies.tf. Resource netpol_keycloak confirmed. Current ingress allowlist: tailscale, westside-ai-assistant, pal-enterprises, landscaping-assistant, monitoring. paldocs is indeed absent, confirming the ticket's description.
• [x] Exclusion terraform/modules/keycloak/ -- verified: directory exists, exclusion is reasonable since Keycloak deployment is unchanged.

Repo Placement

Dependencies

• Downstream: Board item #1387 (paldocs #26 -- "Add paldocs Keycloak OIDC client via Terraform") depends on this. Without NetworkPolicy access, paldocs cannot reach Keycloak for token exchange. Dependency is documented in the Lineage section.
• Downstream (transitive): Board items #1389 (paldocs #28 -- Rails OIDC integration) and #1390 (paldocs #29 -- Role-based visibility filtering) depend on #26, making them transitively dependent on this ticket.
• Sibling: Board item #1704 (pal-e-deployments #224 -- Add KEYCLOAK_* env vars) is independent but part of the same auth story wave.
• No blocking upstream dependencies -- this ticket can proceed independently.

Acceptance Criteria

• [x] AC1: "paldocs namespace added to Keycloak NetworkPolicy" -- verifiable by code review / grep
• [x] AC2: "tofu apply succeeds" -- verifiable by running tofu apply (requires cluster access)
• [x] AC3: "paldocs pod can reach keycloak.keycloak.svc.cluster.local:80" -- verifiable via kubectl exec (paldocs pod is deployed and running)
• [x] Test 1: kubectl exec curl health check -- specific command provided, returns 200
• [x] Test 2: tofu plan shows only NetworkPolicy change -- verifiable, prevents scope creep

Blast Radius

• Low risk: Adding a namespace to an ingress allowlist is purely additive. No existing service connectivity is affected.
• Related gap -- netpol_ollama: The paldocs namespace is still absent from netpol_ollama's ingress allowlist. Currently only pal-e-docs is allowed. If paldocs connects directly to Ollama for embeddings (board item #1562 -- Embedding pipeline is done), this would be blocked. This is a separate concern and does not affect this ticket.
• Pattern consistency: The change follows the established pattern from PR #413 (landscaping-assistant). One-line addition to an existing list.

Decomposition Assessment

• 1 file target across 1 repo -- below threshold
• 3 acceptance criteria -- below threshold
• Estimated agent work: under 2 minutes (add one line to an existing ingress list)

Recommendation