pal-e-docs

Review: Commit prod deployment manifests

review-1358-2026-06-06 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- spike #22, prerequisite for #27
  • [x] Repo -- ldraney/pal-e-deployments (primary), ldraney/westside-ror (tracking)
  • [x] User Story -- present and well-formed
  • [x] Context -- thorough, includes live vs committed comparison
  • [x] File Targets -- present, lists create and do-not-touch files
  • [x] Acceptance Criteria -- 5 items, all testable
  • [x] Test Expectations -- kustomize build command provided
  • [x] Constraints -- present and clear
  • [x] Checklist -- present
  • [x] Related -- lists project and related issues
All required Feature template sections present.

Traceability

  • [x] story:subscription-links label -- present on board item
  • [ ] story note MISSING -- no project-westside-ror project page exists in pal-e-docs at all. [SCOPE] Create project-westside-ror project page with user-stories section.
  • [x] arch:kustomize label -- present on board item
  • [x] arch note verified -- convention-kustomize-overlay exists in pal-e-docs (convention note, not arch note, but this is correct -- kustomize overlays are a convention, not a diagrammable arch component per prior review precedent review-1044-2026-04-21)
  • [x] Forgejo issue -- ldraney/westside-ror#28, open

File Targets

  • [x] overlays/westside-ror/prod/ -- verified: directory does NOT exist yet (correct, these are files to create)
  • [x] overlays/westside-ror/dev/ -- verified: exists with deployment.yaml, service.yaml, kustomization.yaml, ingress.yaml. Issue correctly says "do not touch"
  • [ ] File targets list service.yaml with "if different from dev" qualifier -- ISSUE: the issue should clarify whether the prod service differs. Based on the basketball-api and believers-elite patterns, prod overlays use the bases/standard Service (renamed via JSON patch) rather than a standalone service.yaml. The agent needs explicit guidance. [BODY] Clarify whether service.yaml is needed or if the base Service (renamed via JSON patch in kustomization.yaml) suffices -- per platform convention, prod overlays use bases/standard not standalone resources.

Repo Placement

The issue is filed on ldraney/westside-ror but the work is in ldraney/pal-e-deployments. The issue acknowledges this explicitly (Repo section says "primary: pal-e-deployments, tracking: westside-ror"). This is acceptable -- the tracking issue pattern is established practice. However, the PR should be opened against pal-e-deployments, not westside-ror.

Dependencies

  • Upstream: spike #22 (done per memory) -- no blocker
  • Downstream: #27 (Stripe webhook needs STRIPE_WEBHOOK_SECRET in deployment config) -- this ticket is a prerequisite. Documented in issue.
  • Downstream: #24 (editable fees, safe deploys needed) -- documented in issue.
  • Board state: No blockers in in_progress. Items #2 and #13 are in progress but unrelated (tournament payments/email).

Acceptance Criteria

  • [x] AC1: prod/ overlay exists -- verifiable with ls
  • [x] AC2: deployment patch matches live pod spec -- verifiable with diff
  • [x] AC3: kustomize build produces valid YAML -- verifiable with command
  • [ ] AC4: "deploying from committed manifests produces same pod spec as live" -- ISSUE: this is functionally a superset of AC2+AC3 but harder to verify without cluster access. The agent would need kubectl get deployment -o yaml output to diff against. The issue provides a good description of what's running (Context section) but the agent needs the actual live spec to diff. [BODY] Add a note that the live spec can be captured via kubectl get deployment westside-ror -n westside-ror -o yaml and should be diffed against kustomize build output.
  • [x] AC5: STRIPE_WEBHOOK_SECRET placeholder -- verifiable in the YAML

Blast Radius

Low blast radius. This is a "commit what's running" task -- no behavior change. The only risk is if the committed manifests don't match reality and someone syncs ArgoCD, but that's exactly what this ticket prevents. No sibling services affected.
Note: the dev overlay uses a standalone structure (no bases/standard reference), while the prod overlay should use bases/standard per platform convention. This is not a blast radius concern but an implementation detail the agent must get right.

Decomposition Assessment

3 file targets in 1 repo (pal-e-deployments). 5 acceptance criteria. Estimated agent work: ~3 minutes. No decomposition needed. Well within the 5-minute rule.

Recommendations

  • [SCOPE] Create project-westside-ror project page in pal-e-docs with a user-stories section containing the subscription-links story.
  • [BODY] Clarify the service.yaml file target: per platform convention (convention-kustomize-overlay), prod overlays reference bases/standard and rename via JSON patch. Remove "service.yaml -- if different from dev" and replace with guidance to use the base Service renamed via JSON patch, matching basketball-api/believers-elite patterns.
  • [BODY] Add instruction for the agent to capture the live spec: kubectl get deployment westside-ror -n westside-ror -o yaml > /tmp/live-spec.yaml for diffing against kustomize build output.
  • [BODY] Add explicit note that the prod overlay must use bases/standard (unlike the dev overlay which uses standalone resources). Reference basketball-api and believers-elite as patterns.