pal-e-docs

Review: Fix westside-app Harbor auth (4 alerts)

review-189-2026-03-18 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Lineage
  • [x] Repo
  • [x] User Story
  • [x] Context
  • [x] File Targets
  • [x] Acceptance Criteria
  • [x] Test Expectations
  • [x] Constraints
  • [x] Checklist
  • [x] Related
All required sections present. Context section is excellent — includes root cause analysis, timeline, and skopeo verification.

File Targets

  • [x] ~/pal-e-services/terraform/k3s.tfvars — verified: westsidekingsandqueens service key with image_repo = "westside-app/app" on lines 32-39. Mismatch confirmed.
  • [x] ~/pal-e-services/terraform/services.tf — verified: robot accounts scoped to harbor_project.service[each.key].name (lines 48, 72), meaning the robot gets permissions on Harbor project westsidekingsandqueens, not westside-app.
  • [x] ~/pal-e-deployments/overlays/westsidekingsandqueens/prod/kustomization.yaml — verified: image references point to harbor.tail5b443a.ts.net/westside-app/app with tag c191cdd41ae6ab07a197630e3396c4048f30dc67.
  • [x] ~/pal-e-platform/terraform/ — verified NOT needed: only contains blackbox probe targets for westside (read-only monitoring refs in main.tf lines 465-472).

Repo Placement

Minor concern: The Forgejo issue is filed on forgejo_admin/pal-e-platform, but the issue body correctly identifies that the fix lives in forgejo_admin/pal-e-services (primary) and forgejo_admin/pal-e-deployments. The platform repo only has blackbox probe references. Since this is a cross-cutting platform concern tracked on the platform board, filing it on pal-e-platform is acceptable as an operational tracker, but the agent executing this needs to know to clone and modify pal-e-services, not pal-e-platform. The issue body makes this clear.

Dependencies

  • Board item #188 (Issue #109: Platform cleanup — resolve 15 alerts) is in_progress. This issue (#110) was broken out from that umbrella. No blocking dependency — can proceed independently.
  • Board item #176 (Post-Move Network Recovery) is in_progress — unrelated.
  • Board item #171 (todo: harbor-pull-secret-drift) is next_up — this TODO tracks the general pattern of Harbor pull secret drift. Fixing #110 does not resolve the systemic issue in services.tf; it only fixes the westside-specific mismatch.
  • CI pipelines #19 and #20 on forgejo_admin/westside-app are failing. The CI robot (westsidekingsandqueens-ci) is also scoped to the wrong Harbor project, so CI push is broken too. This is NOT documented in the issue.

Acceptance Criteria

All three acceptance criteria are testable and have concrete verification commands. Test expectations are also well-specified with real commands.
Missing criterion: The issue does not include a CI verification step. After the fix, a Woodpecker pipeline should succeed (build-and-push step). Since CI is also broken by the same root cause, verifying that CI works again should be an acceptance criterion.

Blast Radius

  • CI push is also broken: .woodpecker.yaml in westside-app pushes to westside-app/app (line 24), but the westsidekingsandqueens-ci Woodpecker secret is a robot scoped to Harbor project westsidekingsandqueens. Pipelines #19 and #20 are both failures. The issue only discusses the pull (ImagePullBackOff) side but the push side is equally broken.
  • mcd-tracker-app has a similar tfvars pattern: service key mcd-tracker-app with image_repo = "mcd-tracker/app". However, it is currently working because the image updater wrote back to mcd-tracker-app/app (verified via kubectl describe). This is a latent bug that could surface if the robot is recreated.
  • Option A vs Option B: The issue correctly identifies that Option B (fix services.tf to scope robots to image_repo project) has wider blast radius. If Option A is chosen, it only fixes westside but leaves the systemic bug for mcd-tracker-app and any future services with mismatched keys.
  • Option A side-effects not fully documented: If choosing Option A (change image_repo to westsidekingsandqueens/app), the following also need updating: (1) .woodpecker.yaml repo field in westside-app, (2) kustomization.yaml image references in pal-e-deployments, (3) any ArgoCD image-updater annotations referencing the old path. The issue mentions "CI config in westside-app repo may also need updating" in Constraints but doesn't list the specific files.

Recommendation

Verdict is NEEDS_REFINEMENT. The scope document is high quality — root cause is accurate, file targets verified, and the design decision is well-framed. Three specific refinements needed before dispatching an agent:
  • Document CI breakage: Add that Woodpecker pipelines #19/#20 are failing due to the same robot scope mismatch on the push side. Add acceptance criterion: "Woodpecker pipeline succeeds on next push to main."
  • Make the design decision: Option A or B must be decided before agent dispatch. The issue currently presents both options but doesn't pick one. An agent cannot make this architectural decision.
  • If Option A: enumerate all file changes. Currently the File Targets only list the Option A tfvars change. But Option A also requires changes to westside-app/.woodpecker.yaml (repo field), pal-e-deployments/overlays/westsidekingsandqueens/prod/kustomization.yaml (image name references), and possibly Harbor project cleanup. These should be explicit File Targets.