pal-e-docs

Review: tofu apply to provision notion-mcp-remote

review-1045-2026-04-21 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Single gap: the arch:argocd label has no backing architecture note in pal-e-docs. The ticket's actual architectural anchor is arch-deployment-notion-mcp-remote, which does exist. Everything else is solid and apply-ready pending the two listed dependencies.

Template Completeness

  • [x] Type (Feature)
  • [x] Lineage (references project-notion-mcp-remote, service-onboarding-sop step 5)
  • [x] Repo (forgejo_admin/pal-e-platform)
  • [x] User Story
  • [x] Context (resources provisioned, lock-false + no -target rationale)
  • [x] File Targets ("no file changes in this repo" — apply operation; follow-up-ticket guidance included)
  • [x] Acceptance Criteria
  • [x] Test Expectations (tofu fmt, validate, plan command)
  • [x] Constraints (pre-deploy checklist, secrets pre-provisioned, lock-false, no -target)
  • [x] Checklist
  • [x] Related

Traceability

  • [x] story:ops-deploy-gitops label — "GitOps Deploy via pal-e Platform"
  • [x] story note verified — story-notion-mcp-remote-ops-deploy-gitops listed in project-notion-mcp-remote user-stories section
  • [x] arch:argocd label present on board item
  • [ ] arch note MISSING — no arch-argocd note exists in pal-e-docs. The ticket body references arch-deployment-notion-mcp-remote (which does exist and is the correct architectural anchor for this apply operation)
  • [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/forgejo_admin/pal-e-platform/issues/296 open and valid

File Targets

Issue explicitly states no file changes in pal-e-platform — this is the apply operation itself plus recordkeeping. "Files NOT to touch" (network-policies.tf) is correctly called out. Follow-up-ticket guidance for any plumbing gaps surfaced by tofu plan is appropriate. No file-target verification applicable.

Repo Placement

OK. Apply runs against forgejo_admin/pal-e-platform terraform. Sibling tickets correctly scoped to pal-e-services (#57 var.services entry) and pal-e-deployments (#132 overlay). Application secret provisioning tracked separately on the notion-mcp-remote board. No repo-boundary confusion.

Dependencies

Explicitly documented and present on board-notion-mcp-remote:
  • pal-e-services #57 (var.services entry) — board item 1043, backlog, 3 pts — MUST LAND FIRST
  • pal-e-deployments #132 (kustomize overlay) — board item 1044, backlog, 3 pts — MUST LAND FIRST
  • notion-mcp-remote #7 (secrets kubectl create secret generic) — board item 1047, backlog, 2 pts — MUST LAND BEFORE FIRST ARGOCD SYNC (sibling, not blocker of tofu apply itself, but called out in Constraints to avoid ArgoCD clobbering)
Dependency chain is complete and correctly sequenced.

Acceptance Criteria

Verifiable and concrete:
  • tofu plan -lock=false diff inspection (expected resources enumerated)
  • No unexpected destructive changes
  • Lucas approval gate (explicit)
  • kubectl get ns notion-mcp-remote
  • ArgoCD Application Healthy + Synced
  • Funnel URL (notion-mcp-remote.tail5b443a.ts.net) resolves and returns a pod response
Each criterion is agent-checkable post-apply. Test Expectations section provides the exact plan command: cd terraform && tofu plan -lock=false -var-file=k3s.tfvars.

Blast Radius

Contained. First-deploy apply for a new service with no shared infrastructure modifications:
  • Creates namespace, ArgoCD Application, Harbor project + robots, image pull secret, Tailscale Funnel ingress — all scoped to this service
  • No NetworkPolicy changes (service only egresses to api.notion.com)
  • No Keycloak client (Notion OAuth end-to-end)
  • Risk: a terraform refactor since last apply could surface unrelated diff — the AC "no unexpected destructive changes on unrelated services" covers this and Lucas-gated plan review is the mitigation
  • Aligns with sop-platform-tf-changes (lock-false, Lucas approval, no -target) and service-onboarding-sop step 5 (pre-deploy-validation checklist must be 100% green first)

Decomposition Assessment

No decomposition needed. Single apply operation with one pre-check (plan review) and one gate (Lucas approval). File count: 0. AC count: 7 criteria but all verifiable in a single post-apply pass. Estimated agent work: ~3 min for plan + validation + apply + smoke check. Fits 5-minute rule.

Recommendation

One issue to resolve before this advances out of review:
  • [LABEL] OR [SCOPE] — The arch:argocd label has no backing arch-argocd note. Two options:
All other scope elements (template, dependencies, AC, guardrails, blast radius) are solid. After the label/arch-note decision, this ticket is apply-ready once #57 and #132 merge and the pre-deploy validation checklist is green.