pal-e-docs

Review: Remove ConfigMap, use baked-in email templates

review-753-2026-04-03 Doc

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type — Feature
  • [x] Lineage — present, references basketball-api MJML system ticket
  • [x] Repo — forgejo_admin/pal-e-deployments
  • [x] User Story — clear "who wants what and why"
  • [x] Context — detailed, explains ConfigMap drift problem and coordination order
  • [x] File Targets — present with specific line numbers, verified accurate
  • [x] Acceptance Criteria — 5 testable criteria
  • [x] Test Expectations — YAML validation and kustomize build commands provided
  • [x] Constraints — deployment ordering documented
  • [x] Checklist — present
  • [x] Related — present

Traceability

  • [x] story:WS-S7 label — "As an admin, I want to send branded email announcements so that parent comms are professional and consistent"
  • [x] story note verified — found in project-westside-basketball user-stories section (Admin stories, stories-admin)
  • [x] arch:email label — email architecture component
  • [ ] arch note MISSING — [SCOPE] Create architecture note arch-email for the email component. No arch-email note exists in pal-e-docs.
  • [x] Forgejo issue — forgejo_admin/pal-e-deployments#83, open

File Targets

  • [x] overlays/basketball-api/prod/deployment-patch.yaml — verified exists (98 lines)
  • [x] Lines 77-79: volumeMount email-templates confirmed at exactly those lines
  • [x] Lines 95-97: volume email-templates ConfigMap confirmed at exactly those lines
  • [x] No existing BASKETBALL_EMAIL_TEMPLATES_DIR env var in file — addition is correct
  • [x] basketball-api config.py default is /data/email-templates — env var override to /app/templates/email/compiled/ is the right approach
  • [x] kustomization.yaml — confirmed no changes needed (no ConfigMap generator reference)
Targets are specific enough for an agent to act on without guessing.

Repo Placement

OK. Issue is filed on pal-e-deployments, which owns the kustomize overlays. The deployment-patch.yaml is the correct file. The basketball-api code changes (baking templates into the image) are a separate ticket on the basketball-api repo (Issue #293 / board item 750). Single-repo scope, no cross-repo work needed in this ticket.

Dependencies

  • [x] Board item 750 (Issue #293: MJML email system — brand base + three layouts + docker build) — pending (in backlog). This is the upstream dependency: templates must be baked into the basketball-api Docker image BEFORE this deployment change lands. Issue documents this coordination correctly.
  • [x] Sibling items (751, 752, 658, 735) — all in backlog, all arch:email. Not blockers for this ticket.
  • [x] Board item 724 (contract reminder email endpoint) — in needs_approval. Not a blocker.
Unresolved dependency: board item 750 must complete first. This is documented in the issue Constraints section and is not a blocker for the review — just for execution ordering.

Acceptance Criteria

  • [x] AC1: "no reference to email-templates ConfigMap" — testable via grep, automatable
  • [x] AC2: "BASKETBALL_EMAIL_TEMPLATES_DIR env var set" — testable via grep, automatable
  • [x] AC3: "ArgoCD syncs cleanly" — post-merge validation, appropriate for deployment ticket
  • [x] AC4: "pod starts and email works" — post-merge validation, appropriate
  • [x] AC5: "orphaned ConfigMap deleted" — post-merge manual step via kubectl
AC1-2 are agent-verifiable in PR. AC3-5 are post-merge validations — appropriate for a deployment change. Test Expectations provide concrete commands (YAML validation, kustomize build). No ambiguous language.

Blast Radius

  • pal-e-mail overlay references email templates via MinIO CDN URL, not ConfigMap — no impact
  • No other service overlays in pal-e-deployments reference the email-templates ConfigMap (confirmed via grep)
  • The email-templates ConfigMap is basketball-api namespace only — safe to remove after baked-in templates confirmed working
  • Rollback: re-add ConfigMap volume mount or kubectl apply the ConfigMap again. Straightforward.

Decomposition Assessment

Apply the three-thing limit and five-minute rule:
  • 1 file target, 1 repo — well under 3 discrete changes
  • 3 edits in one file (remove volumeMount, remove volume, add env var) — atomic change set
  • 5 AC total, but only 2 are PR-time verifiable — agent scope is small
  • Estimated agent time: under 5 minutes
  • No independent subtasks that could be parallelized — this is a single atomic change
No decomposition needed.

Recommendation

  • [SCOPE] Create architecture note arch-email for the email component. 7+ board items (750, 751, 752, 753, 658, 724, 735) reference arch:email but no backing architecture note exists in pal-e-docs.