Review: Bug: dead westsidekingsandqueens-funnel ingress

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered during westside-app deployment investigation
• [x] Repo — forgejo_admin/pal-e-services
• [x] What Broke — Clear description with kubectl evidence
• [x] Repro Steps — 3 concrete steps with expected observation
• [x] Expected Behavior — Clear single-funnel expectation
• [x] Environment — Cluster, namespace, SHA, alerts noted
• [x] Acceptance Criteria — 3 criteria, all verifiable
• [x] Related — project and related issue linked

Traceability

• [x] story:superuser-deploy label — board item has this label
• [x] arch:tailscale-funnel label — board item has this label
• [x] Forgejo issue — forgejo_admin/pal-e-services#35, open

File Targets

• [x] services.tf — verified: lines 173-200 define kubernetes_ingress_v1.service_funnel using each.key as backend service name (line 189) and each.value.port (line 191)
• [x] k3s.tfvars — verified: lines 129-136 define westsidekingsandqueens with port = 80 and funnel = true
• [x] kubectl state — verified: westsidekingsandqueens-funnel has no ADDRESS (dead), while westside-app-funnel has the correct address
• [x] No service named westsidekingsandqueens exists — only westside-app (port 3000) and westside-dev (port 80)
• [ ] Issue does not specify exact file targets for the fix — ISSUE: Should explicitly state the fix is funnel = false in k3s.tfvars line 133

Repo Placement

Dependencies

• No blocking dependencies found.
• Board items currently in_progress: 7 items, none related to this funnel work.
• No dependency on the Terraform state splitting (#197) — this change is a simple tfvars edit.
• Related board item #338 (Forgejo #153, type:infra, arch:tailscale-funnel) is already done — was the original funnel infrastructure work that likely introduced this dual-funnel pattern.

Acceptance Criteria

• [x] "westsidekingsandqueens-funnel ingress removed" — verifiable via kubectl get ingress -n westsidekingsandqueens
• [x] "westside-app-funnel continues to serve traffic" — verifiable via curl https://westsidekingsandqueens.tail5b443a.ts.net
• [x] "No regression in site availability" — verifiable via blackbox probe / manual check
• [ ] Missing criterion: after tofu apply, confirm no orphaned Tailscale proxy pod for the dead funnel

Blast Radius

• No other services have this exact conflict. Only westsidekingsandqueens has both funnel = true in tfvars AND a kustomize-managed ingress.yaml in pal-e-deployments.
• Discovered scope: There is a stale westside-app-funnel ingress in the default namespace (hostname westsidekingsandqueens-1) that is NOT covered by this ticket. This is likely from a manual kubectl apply and should be a separate cleanup issue.
• The services.tf funnel resource design assumes backend service name = service key. This assumption breaks when kustomize renames services. This is a systemic design consideration but not a bug in other services currently — only westsidekingsandqueens renames its service.

Recommendation

• Add explicit file target: The issue should state the fix is setting funnel = false in k3s.tfvars line 133 for the westsidekingsandqueens service entry. This makes the fix unambiguous for the implementing agent.
• Add acceptance criterion: "No orphaned Tailscale proxy pod remaining for the removed funnel ingress."
• Discovered scope (separate ticket): Stale westside-app-funnel ingress in default namespace should be tracked as a new cleanup issue.