Function kube_kind 

pub fn kube_kind(value: &Value) -> Option<&str>

Read the top-level kind: string-scalar CRD-discriminator axis of a K8s custom resource YAML document as Option<&str> — the pinned peer on the CRD-discriminator axis to the parametric kube_root_str_field on the top-level <field> sub-axis surface, and the accessor-arity peer that closes the three-arity (accessor / predicate / navigator) closure on the kind: discriminator axis: kube_kind reads, kube_kind_is tests, find_by_kind locates — the structural mirror of the same closure the sibling metadata.name identity axis (accessor kube_name c9cdecb, predicate kube_name_is 092965d, navigator find_by_name 092965d) and the sibling metadata.namespace namespace-scoping axis (accessor kube_namespace e18297b, predicate kube_namespace_is 9f4a600, navigator find_by_namespace 9f4a600) already close on the two sub-metadata.* coordinates.

Returns None when either the top-level kind: scalar is absent or the kind: scalar carries a non-string YAML type — the same two-way vacuous-None short-circuit the parent kube_root_str_field closes on the underlying one-hop navigation.

The KUBE_KEY_KIND axis is pinned inside the helper (unlike the parametric field axis of the underlying kube_root_str_field) because the K8s CRD schema pins kind as the load-bearing per-CR discriminator on every CustomResource across every group/version (paired with apiVersion for CRD-registration disambiguation) — the same load-bearing status the sibling metadata.name + metadata.namespace coordinates carry on the sub-metadata: axis pair that already lifted an accessor peer under the same discipline. Every readback consumer downstream (.unwrap(), .expect(...), == Some(...) equality wraps, .to_string() clone) drives off the same pinned return; a hypothetical future K8s API-machinery rebrand on the kind: axis (a schema-migration to a wrapped kindV2: scalar under a per-group versioning axis, a Server-Side-Apply-driven per-field-ownership migration under an aliased resource: scalar) reaches every caller through one lift, not a coordinated rewrite across every per-CR discriminator readback site.

The canonical shape 7 emit-side test-harness readback sites across caixa-flux (3) + caixa-mesh (4) previously carried inline as the two-token composition

kube_root_str_field(<value>, KUBE_KEY_KIND)

around a one-token semantic payload (the readback intent — “what kind did the emitter write into this CR?”). The lift collapses the two-token composition — the parametric readback helper, the pinned discriminator-axis scalar-key argument — onto one accessor the caller reads as intent (kube_kind(<value>) — “what is this K8s CR document’s top-level kind:?”) rather than a readback → axis-pin two-arg call. Peer predicates for other top-level discriminators (a hypothetical kube_api_version accessor on a multi-version migration harness, a kube_group accessor for CRD-group filtering) land as sibling helpers with their own pinned axis, not as re-parameterizations of this one.

Structural peer to sibling kube_name (c9cdecb) / kube_namespace (e18297b) on the two sub-metadata.* coordinates: kube_name closes the accessor arity on the identity axis; kube_namespace closes it on the namespace-scoping axis; kube_kind closes it on the top-level CRD-discriminator axis. Same accessor-arity shape, different pinned scalar-key on a different navigation depth (root vs sub-metadata:) — together the three accessors bracket the K8s-CR YAML readback surface every renderer + every test-side per-CR readback path reaches through, closing the three-arity (accessor / predicate / navigator) structural closure on each of the three canonical per-CR coordinates the K8s API-machinery pins as load-bearing per-CR axes.

Sites lifted:

• caixa-flux’s three cluster_bundle_{gitrepository,helmrelease,kustomization}_uses_lifted_flux_kind_<crd> tests — each per-emitted-file kube_root_str_field(&parsed, KUBE_KEY_KIND) == Some(FLUX_KIND_<CRD>) lifted-uses pin on the per-Flux-CR bundle-path emission (gitrepository.yaml, helmrelease.yaml, kustomization.yaml — the three Flux v2 controller-triplet CRD kinds);
• caixa-mesh’s per-CNP top-level kind: readback loop in the two test bodies cilium_network_policies_use_lifted_cilium_kind_network_policy and cilium_policy_carries_canonical_kube_skeleton — each for p in &policies { assert_eq!(kube_root_str_field(p, KUBE_KEY_KIND), Some(CILIUM_KIND_NETWORK_POLICY)); } loop over the multi-doc CNP emission;
• caixa-mesh’s per-Gateway / per-HTTPRoute top-level kind: readback across the two test bodies gateway_routes_gateway_uses_lifted_gateway_api_kind_gateway and gateway_routes_httproute_uses_lifted_gateway_api_kind_http_route — each find_by_kind(&docs, <KIND>) → kube_root_str_field(_, KUBE_KEY_KIND) == Some(caixa_core::GATEWAY_API_KIND_<CRD>) chain over the paired-Gateway/HTTPRoute emission.

Every future per-CR kind: readback (the future per-:politicas CiliumClusterwideEnvoyConfig emitter’s per-CR discriminator pin, MESH-COMPOSITION §III.2 #3; the future app-operator’s mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-status discriminator readback, §III.2 #5; the future M4 cross-cluster fan-out’s per-cluster HelmRelease vs Kustomization split by kind:) reaches the same pinned accessor by construction, with no axis-key argument drift and no re-inlined kube_root_str_field(_, KUBE_KEY_KIND) two-token composition.