ci: validate FeatureFlag definitions against the flagd schema before deploy #4223

🤖 Generated by the Agentic Engineer

Evidence

The OpenFeature Operator is installed (#2527, from #2510) and the platform's contract documents FeatureFlag CRs as the runtime flag layer. No FeatureFlag CR exists yet: on 2026-09-27 neither tenant web app references OpenFeature, and the platform has no workload that consumes a flag. The FeatureFlag CRD is installed at runtime, so the contract already tells the first flag to add its kinds to validation.skipKinds — which means a flag's definition is not checked before deploy at all.

Audience and problem

Whoever adds the platform's first runtime flag. A malformed flag definition (a missing default variant, a variant type mismatch, a bad targeting rule) is accepted by Git and CI and only fails when flagd loads it, in the cluster.

Hypothesis and success signal

If CI checks each FeatureFlag CR's flag definitions against flagd's published flag schema, a malformed flag fails the pull request instead of the running workload. Success: a deliberately malformed fixture fails the check and a valid one passes; the first real flag goes through it.

Acceptance criteria

• CI validates the flag definitions in every FeatureFlag CR in the repository against flagd's flag schema, pinned to a version.
• The check has a valid and an invalid fixture, and the invalid one proves it fires.
• With no FeatureFlag CR present, the check says so explicitly rather than reporting a pass over nothing.
• The contract's feature-flag section points at the check.

Size

S. Best landed with the first real flag, but it can ship on its own with fixtures.