Review: tofu apply blocked by MinIO provider refresh

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- references PRs #192, #195
• [x] Repo -- forgejo_admin/pal-e-platform
• [x] What Broke -- clear error pattern with log output
• [x] Repro Steps -- 5-step reproduction
• [x] Expected Behavior -- describes desired state with 3 solution options
• [x] Environment -- cluster, namespace, service URL, tofu version, provider version
• [x] Acceptance Criteria -- 3 criteria
• [x] Related -- references #194, #195, #192, project-pal-e-platform

Traceability

• [x] story:superuser-deploy -- deploy reliability story
• [x] arch:ci-pipeline -- CI pipeline architecture component
• [x] arch:minio -- MinIO architecture component
• [x] Forgejo issue -- #196, open

File Targets

• [x] terraform/providers.tf (lines 16-21) -- root-level minio provider config. Confirmed: provider initializes on every plan/apply regardless of module targeted.
• [x] terraform/modules/storage/main.tf -- all minio_* resources (buckets, IAM users, policies) live here after #197 modularization.
• [x] terraform/modules/storage/versions.tf -- module declares minio provider ~> 3.5
• [x] .woodpecker.yaml (lines 192-217) -- apply step passes minio_server var, no retry logic for provider connectivity failures.
• [x] terraform/network-policies.tf (line 123) -- MinIO netpol allows ingress from woodpecker namespace. Network policy is not the blocker.

Repo Placement

Dependencies

• #197 (Terraform state splitting) -- CLOSED/DONE. The modularization that #196's "Expected Behavior" section describes as a solution has already shipped. MinIO resources are now in module.storage. However, the root-level minio provider in providers.tf still initializes on every apply.
• #198 (CI pipeline targeted apply) -- OPEN, in todo column. This is the follow-up that would make tofu apply -target=module.ci work in CI, skipping the minio provider entirely for Helm-only changes. This is the real permanent fix.
• #184 (Harbor connectivity timeout) -- in_progress. Related CI connectivity issue.

Acceptance Criteria

• "Helm-only changes can apply without MinIO provider blocking them" -- This is what #198 delivers. Not independently testable from #196.
• "Apply reliability improves from ~50% to >95% success rate" -- Measurable but vague on mechanism. After #197+#198, this should be automatic.
• "No regression on MinIO resource management" -- Standard regression check, testable.

Blast Radius

• The MinIO provider connectivity issue affects ALL tofu applies, not just Helm changes. Any PR merge triggers a full refresh including MinIO resources.
• The pal-e-services repo is NOT affected -- it has its own Terraform root with no MinIO provider.
• No other repos consume this provider.

Recommendation

• Option A: Close as duplicate/superseded. #197 + #198 together fully address all three acceptance criteria. #196 adds no independent work.
• Option B: Repurpose as a short-term mitigation. Add provider-level timeout/retry config to the minio provider block in providers.tf, or add retry logic in .woodpecker.yaml apply step. This would be a stopgap until #198 lands. If this path is chosen, rewrite the acceptance criteria to target the specific mitigation.