Review: Onboard westside-admin: Harbor project + CI robot account via terraform

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Task
• [x] Lineage — cites discovery during #1094 scope review
• [x] Repo — forgejo_admin/pal-e-services
• [x] User Story — story-westside-admin-admin-row-crud, foundational
• [x] Context — describes existing onboarding pattern + names sibling services
• [x] Scope — clear: add k3s.tfvars entry, run tofu plan/apply
• [x] Acceptance Criteria — 6 criteria, all testable
• [x] Test Expectations — tofu plan review + Harbor UI check + first kaniko push
• [x] Constraints — tofu (not terraform), -lock=false, naming convention nailed
• [x] Checklist — present
• [x] Related — project, arch, conventions, blocks linkage

Traceability

• [x] story:admin-row-crud label — admin row CRUD story
• [x] story note verified — story-westside-admin-admin-row-crud exists; listed in project-westside-admin user-stories section
• [~] arch:k8s-deploy label — misaligned. This ticket provisions Harbor projects + robot accounts (registry/IAM concern), not k8s deployment topology. arch:k8s-deploy is correctly used on #1095 (kustomize overlay). Recommend arch:harbor (matches sibling #1088) or arch:deployment-westside-admin (matches the arch note explicitly cited in Related). [LABEL]
• [ ] arch note MISSING — no arch-k8s-deploy note exists in pal-e-docs (search returned 0 results). The arch label needs to point to a real backing note. [SCOPE]
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/forgejo_admin/pal-e-services/issues/64, open

File Targets

• [x] ~/pal-e-services/terraform/k3s.tfvars — verified exists. Contains a services = { ... } map with 11 active entries. Schema confirmed: forgejo_repo, image_repo, port, funnel, source_repo, source_path. Reference entry westsidekingsandqueens (lines 224-231) uses key westsidekingsandqueens, image_repo = "westsidekingsandqueens/app". Mirroring confirmed feasible.
• [x] ~/pal-e-services/terraform/services.tf — verified exists. Line 7 comment: "service key = Harbor project name = image_repo prefix. No dedup needed when naming is consistent." Line 13: name = each.key on harbor_project.service. Lines 24, 60: robot accounts named ${each.key}-ci and ${each.key}-pull. Module is for_each over var.services, so adding one entry to k3s.tfvars provisions the full stack (Harbor project, both robot accounts, namespace, image pull secret, ArgoCD app, optional funnel).
• [x] Reference entry westsidekingsandqueens (services.tf-driven, k3s.tfvars:224-231) — matches scope description exactly.

Repo Placement

Dependencies

• This ticket BLOCKS: #1094 (forgejo_admin/westside-admin#8 — Woodpecker CI cannot push), #1095 (forgejo_admin/pal-e-deployments#133 — ArgoCD overlay cannot pull image). Documented in Related.
• This ticket has no upstream blockers. Independent of scaffolding (#1087) and Dockerfile work — can run in parallel.
• No in_progress items conflict. Only #1093 (page-server) is in todo; rest of board is backlog.
• State lock note: ticket correctly invokes feedback_tofu_lock_false (-lock=false on plan). Keycloak/CNPG entries co-resident in same tfvars; modifying only services map limits drift surface.

Acceptance Criteria

• k3s.tfvars entry: trivial diff check.
• tofu fmt + tofu validate: standard pre-PR gate.
• tofu plan -lock=false output in PR shows ONLY new additions: verifiable by reviewer.
• Harbor project exists post-apply: Harbor UI check.
• CI robot account exists with push perms: Harbor UI check.
• Credentials wired: ambiguous — ACs say "(or document how the new project authenticates)". Per service-onboarding-sop, robot creds are per-service via the kubernetes_secret_v1.harbor_creds resource in services.tf (image pull secret harbor-creds in the namespace). For Woodpecker push secrets specifically, need to verify whether existing harbor_username/harbor_password global Woodpecker secrets work for the new project (Harbor project-level robot creds vs system-level creds). Dev should verify and document explicitly. [BODY]

Blast Radius

• services.tf:7 comment: "service key = Harbor project name = image_repo prefix"
• services.tf:13: harbor_project.service uses name = each.key
• 11 existing entries in k3s.tfvars: keys are westsidekingsandqueens, basketball-api, pal-e-app, pal-e-docs, mcd-tracker, mcd-tracker-app, gcal-scheduler, pal-e-mail, westside-ai-assistant, playme2k, platform-validation. None use Forgejo owner (forgejo_admin) as project name.
• Ticket explicitly says (Constraints): "Service key naming: westside-admin (NOT forgejo_admin/westside-admin — owner namespace is irrelevant per feedback_harbor_project_naming)." This is exactly right.

Decomposition Assessment

Recommendation

• [LABEL] Replace arch:k8s-deploy with arch:harbor (matches #1088) or arch:deployment-westside-admin (matches the arch note in Related). arch:k8s-deploy belongs to #1095 (overlay), not this Harbor-provisioning ticket.
• [SCOPE] Either create arch-k8s-deploy note (if keeping the label) or rely on existing arch-deployment-westside-admin. Recommend the latter for consistency with sibling tickets.
• [SCOPE] Fix doc drift in arch-deployment-westside-admin: the "Harbor registry" row says project=forgejo_admin and image path=harbor.tail5b443a.ts.net/forgejo_admin/westside-admin:<sha>. Update to project=westside-admin, image path=harbor.tail5b443a.ts.net/westside-admin/app:<sha>. Also fix the "Key Decisions" bullet "Image registry follows Harbor naming convention" which has the same error. Without this, #1094 and #1095 risk inheriting wrong values. Could be a one-line cleanup ticket OR fold into this ticket's PR.
• [BODY] Verify and document the chosen port for the service entry (likely 3000 per arch note's SvelteKit adapter-node design, NOT 80). Pre-empts a later mismatch with #1095 overlay's Service definition.
• [BODY] Verify Woodpecker secret model: does the new westside-admin-ci robot account need its own per-repo secrets in Woodpecker, or do existing global secrets work? Document the answer in the AC explicitly — currently AC says "or document how the new project authenticates," which leaves the dev guessing.