pal-e-docs

Review: Harbor pull secret for staging image (re-review)

review-1932-2026-07-26-r2 Review

review ready
Project

Verdict: READY

Re-review after refinement. Both requested fixes confirmed: Test Expectations section added, board label corrected from type:feature to type:task.

Template Completeness

  • [x] Type -- Task
  • [x] Lineage -- Follow-up from #193, discovered during PR #196 review
  • [x] Repo -- ldraney/pal-e-services
  • [ ] User Story -- Omitted; acceptable for foundational infra task
  • [x] Context -- Clear explanation of cross-project pull access gap
  • [x] Scope -- Replaces File Targets correctly for Task type
  • [x] Acceptance Criteria -- 3 items, all verifiable
  • [x] Test Expectations -- Added in refinement; 3 concrete checks
  • [x] Constraints -- Generic solution requirement stated
  • [x] Checklist -- Standard items
  • [x] Related -- References #193 parent and arch-argocd

Traceability

  • [x] story:dev-environment label -- verified in project-iss user-stories section
  • [x] story note verified -- "dev-environment" row exists: "Dev to staging to prod pipeline"
  • [x] arch:infra label -- infrastructure category
  • [x] arch note verified -- arch-infra note exists in pal-e-docs
  • [x] Forgejo issue -- svc#199, open

File Targets

N/A -- Task type uses Scope section. Verified the scope is accurate: services.tf lines 98-118 create pull robots scoped per-project via harbor_project.service[each.key].name. The staging service entry in k3s.tfvars (line 387-394) shares image_repo = "intelligentstaffingsystems/app" with prod but gets its own Harbor project intelligentstaffingsystems-staging, confirming the cross-project pull gap.

Repo Placement

Correct. The Harbor robot and pull secret logic lives in pal-e-services/terraform/services.tf. The Forgejo issue is filed on ldraney/pal-e-services. Single repo fix.

Dependencies

  • #193 (staging environment) -- done, parent of this issue
  • Sibling staging tickets on board: svc#198 (Caddy), platform#560 (DNS), deploy#242 (CNPG database) -- parallel, not blocking
  • No upstream blockers identified

Acceptance Criteria

3 criteria, all agent-verifiable:
  • "Staging pods can pull images" -- verifiable via kubectl
  • "Terraform manages access" -- verifiable via terraform plan output
  • "Must not weaken prod access controls" -- verifiable by reviewing terraform diff for read-only scope
Test Expectations align with AC: terraform plan check, kubectl pod status check, no manual steps required.

Blast Radius

Low. ISS is currently the only service with a staging variant (image_updater defaults to true in variables.tf). The constraint requiring a generic solution ensures future staging services benefit. No other services currently share images across Harbor projects.

Decomposition Assessment

No decomposition needed. Single repo (pal-e-services), likely 1-2 terraform files, 3 acceptance criteria, estimated under 5 minutes of agent work.

Recommendation

No action needed.