Review: Validate pal-e-platform (3 merged + #222 pending)

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Task
• [x] Scope — present (replaces File Targets for Task type)
• [x] User Story — present
• [x] Acceptance Criteria — present (7 items)
• [x] Constraints — present
• [x] Related — present
• [ ] Lineage — partial, inline text "Validation audit" but not formatted per template
• [ ] Repo — missing (implicit: pal-e-platform)
• [ ] Context — missing, no background section explaining the session or what led to these PRs
• [ ] Test Expectations — inline in Scope, not a separate section with runnable commands
• [ ] Checklist — missing (PR opened / Tests pass / No unrelated changes)

Traceability

• [x] story:superuser-deploy label — present on board item #512
• [x] arch:ci-pipeline label — present on board item #512
• [x] Forgejo issue — #223, open
• [x] type:task label — present
• [x] scope:validation label — present

File Targets

• [x] terraform/modules/staging/main.tf — verified exists on forgejo/main (commit 0e313e5). Creates kubernetes_namespace_v1.staging with correct labels.
• [x] terraform/main.tf — verified: module.staging wired with source = "./modules/staging". No depends_on (all other modules that need ordering have explicit depends_on).
• [x] terraform/network-policies.tf — verified: netpol_staging references module.staging.staging_namespace with field_manager force_conflicts. Pattern matches all 9 other netpol resources.
• [x] terraform/outputs.tf — referenced in PR #218 description, exposes staging_namespace.

Repo Placement

Dependencies

• Board item #411 (Harbor connectivity timeout, in_progress) — shares arch:ci-pipeline label. If Harbor is broken for CI, the validation pipeline may also fail for image-pull reasons, not just staging namespace. This dependency is NOT documented in the issue.
• Board item #515 (Validate: pal-e-deployments, backlog) — sibling validation task with arch:k8s-deploy. If pal-e-platform staging namespace does not exist, pal-e-deployments staging overlays will fail. Sequential dependency: #512 must complete before #515.
• PR #222 — correctly gated behind CI verification. PR is open, not merged. The issue scope explicitly says "Do NOT merge PR #222 until pal-e-platform CI is verified green." Good.

Acceptance Criteria

• AC1 "Pipeline #350 failure diagnosed — root cause documented" — testable: read Woodpecker logs, document findings. The investigation comment already has a partial diagnosis.
• AC2 "tofu plan succeeds cleanly" — testable: tofu plan -lock=false on archbox.
• AC3 "tofu apply succeeds or path to success is clear" — partially testable. "Path to success is clear" is subjective — needs sharper criteria.
• AC4 "PR #222 merged after CI is verified green" — testable but depends on AC1-AC3 completing first.
• AC5 "Pipeline verified" — vague. Which pipeline? Pipeline #350 retry? A new pipeline triggered by PR #222 merge?
• AC6 "Deployment confirmed" — vague. Confirmed how? kubectl get ns staging? ArgoCD sync?
• AC7 "Features validated" — vague. Which features? PRs #216 (nftables), #217 (internal URLs), #218 (staging namespace)?

Blast Radius

• Staging namespace creation is NEW infrastructure — no existing resources are affected. The netpol follows the same pattern as all 9 existing netpols (kubernetes_manifest with field_manager force_conflicts).
• The investigation comment's theory #1 (missing depends_on) is plausible: module.staging has no depends_on in root main.tf, but other modules (ci, harbor, ops) do. However, the staging module is self-contained (no cross-module inputs), so Terraform should create the namespace before the netpol that references it via the implicit dependency through module.staging.staging_namespace.
• Theory #2 (CI RBAC for namespace creation) is more likely — this is the first time CI has tried to create a brand-new namespace via tofu apply since the modularization. Previous namespaces were migrated via moved{} blocks.
• The Woodpecker log truncation is a separate issue: the apply step redirects to /tmp/apply-output.txt then cats it, but the log was cut off in the Woodpecker capture. This makes CI debugging harder.

Decomposition

• 7 acceptance criteria (exceeds 5-AC threshold)
• Multi-step sequential work: diagnose → fix → plan → apply → merge PR → verify → validate
• Estimated agent work: well over 5 minutes (diagnosis alone requires manual archbox investigation per the issue's own Constraints section)
• Mixed concern types: CI debugging (AC1), infrastructure operations (AC2-AC3), PR management (AC4), and feature validation (AC5-AC7)

• Diagnose pipeline #350 failure — run tofu plan -lock=false on archbox, capture error, document root cause
• Fix and apply staging module — implement fix (RBAC, depends_on, or whatever root cause reveals), run tofu apply, verify namespace exists
• Merge PR #222 and validate — merge after CI green, verify pipeline, confirm all 3 merged PR features work

Recommendation

• [BODY] Add ### Repo section: forgejo_admin/pal-e-platform
• [BODY] Add ### Context section explaining the session 2026-03-28 merge batch and why these 4 PRs are grouped
• [BODY] Sharpen AC5-AC7: specify exact verification commands (kubectl get ns staging, pipeline number, which features to check and how)
• [BODY] Add ### Checklist section per template
• [BODY] Document dependency on board item #411 (Harbor CI connectivity) — if Harbor is down, apply may fail for unrelated reasons
• [BODY] Document sequential dependency: #512 must complete before #515 (pal-e-deployments validation)
• [SCOPE] The Constraints section says "This needs manual investigation with tofu plan on archbox" — this is a human-in-the-loop gate that makes full automation impossible. Clarify: is step 1 (diagnosis) manual-only, with subsequent steps dispatchable to agents?
• [DECOMPOSE] 7 AC across sequential phases with a manual gate. Split into 3 tickets via template-board: (1) diagnose, (2) fix+apply, (3) merge+validate.