pal-e-docs

Review: svc#199 Harbor pull secret for staging image

review-1932-2026-07-26 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type -- present (Task)
  • [x] Lineage -- present (follow-up from #193)
  • [x] Repo -- present (ldraney/pal-e-services)
  • [ ] User Story -- missing (foundational infra work, acceptable for Task type)
  • [x] Context -- present, well-explained
  • [x] Scope -- present (replaces File Targets for Task type)
  • [x] Acceptance Criteria -- present (3 criteria)
  • [ ] Test Expectations -- MISSING
  • [x] Constraints -- present
  • [x] Checklist -- present
  • [x] Related -- present

Traceability

  • [x] story:dev-environment label -- present on board item
  • [x] story note verified -- found in project-iss user-stories section (backing: #192 / #193 / #194 + docs/pipeline.md)
  • [x] arch:infra label -- present on board item
  • [x] arch note verified -- arch-infra note exists in pal-e-docs (covers infrastructure patterns; note is paldocs-scoped but the arch label is valid)
  • [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/pal-e-services/issues/199, open

File Targets

Task type -- no file targets required. Scope section describes the work (grant staging pull robot cross-project access in terraform).

Repo Placement

OK. Issue filed on ldraney/pal-e-services, which is where the terraform service definitions and Harbor robot configuration live. No repo mismatch.

Dependencies

  • Parent: svc#193 (staging environment) -- done on board (#1893)
  • Sibling staging tickets in backlog: svc#198 Caddy reverse proxy (#1931), platform#560 DNS CNAME (#1930), deploy#242 CNPG database (#1928)
  • This ticket is a prerequisite for staging pods to pull images -- it unblocks staging deployment functionality
  • Dependencies are partially documented in the Related section (#193 parent, arch-argocd) but sibling staging tickets are not cross-referenced

Acceptance Criteria

3 criteria, all verifiable:
  • "Staging pods can pull intelligentstaffingsystems/app images" -- verifiable via kubectl on staging namespace
  • "No manual Harbor configuration -- terraform manages the access" -- verifiable by inspecting terraform plan output
  • "Must not weaken prod Harbor project access controls" -- verifiable by reviewing terraform diff and Harbor project member list
AC are clear and testable. Count is under the 5-threshold.

Blast Radius

The ISS repo's .woodpecker.yaml pushes images to harbor.tail5b443a.ts.net. The issue correctly identifies that the solution should be generic (any service sharing images across staging/prod). Other services with staging variants would benefit from the same cross-project pull pattern. No immediate sibling services in the ISS repo are affected -- the blast radius is contained within pal-e-services terraform.

Decomposition Assessment

No decomposition needed. Single repo (pal-e-services), 3 AC, estimated agent work under 5 minutes (terraform configuration change for Harbor robot permissions).

Recommendation

  • [LABEL] Fix type label mismatch: board item has type:feature but issue body says ### Type: Task. Change board label to type:task.
  • [BODY] Add ### Test Expectations section. Suggested content: terraform plan shows robot member added to prod Harbor project; kubectl get pods -n intelligentstaffingsystems-staging shows no ImagePullBackOff; no manual Harbor console steps required.