pal-e-docs

Review: Landing site rename

review-450-2026-03-27 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type — Feature
  • [x] Lineage — Standalone, architectural decision
  • [x] Repo — forgejo_admin/westside-app
  • [x] User Story — clear superadmin persona
  • [x] Context — good explanation of current vs desired naming
  • [x] File Targets — 6 modify targets, 3 exclusions
  • [x] Acceptance Criteria — 6 items
  • [x] Test Expectations — 4 items including curl smoke test
  • [x] Constraints — 5 constraints including atomicity requirement
  • [x] Checklist — present
  • [x] Related — 4 items
All required template sections present. Well-written scope.

Traceability

  • [x] story:WS-S26 label — Westside Season 26 story
  • [x] arch:landing-site label — landing site architecture component
  • [x] Forgejo issue — forgejo_admin/westside-app#109, open
Traceability triangle complete.

File Targets

  • [x] pal-e-services/terraform/k3s.tfvars — VERIFIED: line 130 has forgejo_repo = "forgejo_admin/westside-app" under the westsidekingsandqueens service key. Needs updating to forgejo_admin/westside-landing.
  • [x] pal-e-deployments/overlays/westsidekingsandqueens/ — VERIFIED: prod and dev overlays exist. Prod has 18+ references to "westside-app" across kustomization.yaml, ingress.yaml, and deployment-patch.yaml (k8s Service name, Deployment name, Secret names, Ingress name). These are k8s resource names, NOT repo names — see Issue 1 below.
  • [x] pal-e-platform/terraform/modules/monitoring/main.tf — VERIFIED: lines 366-368 contain blackbox probe named "westside-app" pointing to http://westside-app.westsidekingsandqueens.svc.cluster.local:3000.
  • [x] .woodpecker.yaml — VERIFIED: clone URL uses ${CI_REPO} (line 14). No hardcoded repo name. Correctly marked as verify-only.
  • [ ] Forgejo repo rename API — not verifiable in filesystem, but Forgejo API supports PATCH /repos/{owner}/{repo}.
  • [ ] Woodpecker webhook + secrets — not verifiable in filesystem. Noted as "may need re-creation."

ISSUES FOUND

Issue 1: Scope confusion between repo name and k8s resource names (CRITICAL)

The ticket says "rename westside-app repo to westside-landing" but many file targets contain "westside-app" as a Kubernetes resource name (Deployment, Service, Ingress, Secret), not a repo reference. The k8s resource names are independent of the Forgejo repo name. The ticket must clarify:
  • Are k8s resources (Deployment name, Service name, Secret name) also being renamed to westside-landing?
  • If yes, this is MUCH larger blast radius — the blackbox probe URL changes, the Ingress service reference changes, the Secret name changes, cross-namespace NetworkPolicy comments in basketball-api reference "westside-app."
  • If no, most pal-e-deployments changes are unnecessary — only the ArgoCD source repo reference needs updating.
The pal-e-services/terraform/k3s.tfvars only needs forgejo_repo updated. The image_repo is already westsidekingsandqueens/app (Harbor project), which is correct and repo-name-independent.

Issue 2: Keycloak client key collision (UNDOCUMENTED RISK)

The keycloak_clients map in k3s.tfvars uses westside-app as both the map key AND the client_id (line 41-43). The ticket says "don't touch Keycloak" but the Keycloak client_id is westside-app. If this repo rename is Phase 1 of freeing up the name westside-app for the future auth portal, there is a naming collision: the Keycloak client for the landing site is called westside-app. This needs explicit acknowledgment as a Phase 2/3 concern or addressed here.
The keycloak-import.sh script also references westside-app (lines 13, 28-29).

Issue 3: Multi-repo PR scope unclear

The Checklist says "PR opened (for pal-e-services + pal-e-deployments changes)" — but Forgejo PRs are per-repo. This needs 2 separate PRs minimum, plus the Forgejo API rename call, plus a potential pal-e-platform PR for the blackbox probe. The ticket should enumerate which repos get PRs.

Issue 4: Harbor criterion likely no-op

Acceptance criteria says "Harbor project updated or new project created" but Harbor project is westsidekingsandqueens (derived from image_repo prefix per feedback_harbor_project_naming.md). This is already correct and repo-name-independent. Confirm or remove the criterion.

Issue 5: Missing file target — dev overlay hostPath

pal-e-deployments/overlays/westsidekingsandqueens/dev/deployment.yaml:50 has hostPath /home/ldraney/westside-app. After rename, the local clone directory path may change. This should be listed in file targets.

Repo Placement

Issue filed on forgejo_admin/westside-app — correct, this is the repo being renamed. Fix touches 3-4 repos:
  • westside-app (Forgejo rename API, no code change)
  • pal-e-services (tfvars update)
  • pal-e-deployments (ArgoCD source reference, possibly k8s names)
  • pal-e-platform (blackbox probe name — cosmetic only if k8s Service name stays)

Dependencies

  • Board #416 (next_up) "Svelte promotion prep" — arch:landing-site, no direct dependency but should be aware of rename.
  • Board #438 (done) "CI image repo mismatch" — prior Harbor naming bug confirms Harbor project is already westsidekingsandqueens.
  • Board #467 (in_progress) — admin-dashboard work, no dependency.
  • No blockers found.

Acceptance Criteria

  • [x] "Repo renamed to westside-landing on Forgejo" — verifiable via API
  • [x] "CI pipeline builds and pushes successfully" — verifiable with no-op commit
  • [x] "ArgoCD syncs under new repo reference" — verifiable via kubectl
  • [x] "Site remains live" — verifiable via curl
  • [x] "No broken webhooks or secrets" — verifiable via Woodpecker
  • [ ] "Harbor project updated or new project created" — likely no-op, needs clarification

Blast Radius

  • basketball-api kustomization has commented-out NetworkPolicy reference to westside-app cross-namespace access. If k8s names change, comment becomes stale.
  • Keycloak client_id is westside-app — unchanged by this ticket but creates naming confusion for future auth portal.
  • Dev overlay hostPath references /home/ldraney/westside-app — local clone path will change after rename.
  • No other services reference the repo name directly.

Decomposition Assessment

  • If k8s names DON'T change: ~3 file changes across 2 repos + 1 API call. Fits single agent.
  • If k8s names DO change: 10+ file changes across 4 repos. Exceeds single agent. Needs decomposition via template-board.

Recommendation

  • Clarify k8s resource naming — State explicitly whether k8s Deployment/Service/Ingress/Secret names change from westside-app to westside-landing, or stay as-is.
  • Clarify Keycloak client_id collision — Acknowledge that the Keycloak client_id westside-app will conflict with the future auth portal. State whether deferred to Phase 2/3.
  • Fix PR scope — Enumerate which repos get PRs. One PR per repo.
  • Resolve Harbor criterion — Confirm no-op or remove acceptance criterion.
  • Add dev overlay hostPath to file targets.