apiVersion: helm-expt.confighub.com/v1alpha1
kind: ProductionDispositionReceipt
metadata:
  name: jetstack-cert-manager-scan-gate-warning-disposition
spec:
  chart: jetstack/cert-manager
  version: "v1.20.2"
  disposition: scan/gate warning disposition
  decision: accepted
  acceptedAt: "2026-06-09"
  scope:
    - local-test
    - production-review-input
  summary: cert-manager has no high or critical rendered-object scan findings. The local scan warnings are CRD lifecycle, webhook observation, Helm startup API hook lifecycle, and cluster RBAC review points. The external kube-linter warnings are missing CPU and memory requirements on the cert-manager controller, cainjector, and webhook Deployments in each base. This disposition accepts those warnings as explicit production review inputs, not as final production support.
  evidence:
    - path: data/external-scan-lane/review.csv
      claim: External kube-linter rows for both bases record unset-cpu-requirements and unset-memory-requirements warnings bound to rendered object digests.
    - path: data/scan-disposition-workdown/workdown.csv
      claim: The generated scan disposition workdown routes cert-manager to add-resource-policy before production support.
    - path: recipes/jetstack/cert-manager/v1.20.2/revisions/default/r001/receipts/scan-receipt.yaml
      claim: The default rendered-object scan has zero high or critical findings and records webhook, hook lifecycle, and cluster RBAC review points explicitly.
    - path: recipes/jetstack/cert-manager/v1.20.2/revisions/crds-enabled/r001/receipts/scan-receipt.yaml
      claim: The crds-enabled rendered-object scan has zero high or critical findings and records CRD, webhook, hook lifecycle, and cluster RBAC review points explicitly.
    - path: data/production-disposition/receipts/jetstack-cert-manager/crd-lifecycle-and-upgrade-policy.yaml
      claim: CRD ownership and default target preconditions have an accepted production-review disposition.
    - path: data/production-disposition/receipts/jetstack-cert-manager/webhook-readiness-and-failure-policy.yaml
      claim: Webhook readiness, caBundle, and API dry-run expectations have an accepted production-review disposition.
    - path: data/production-disposition/receipts/jetstack-cert-manager/hook-and-lifecycle-phase-policy.yaml
      claim: The startup API check Helm hook has an accepted lifecycle route through post-apply observation.
    - path: data/production-disposition/receipts/jetstack-cert-manager/cluster-rbac-review.yaml
      claim: Cluster-scoped RBAC has an accepted production-review disposition.
    - path: data/production-disposition/receipts/jetstack-cert-manager/extension-slot-provenance-and-scan-policy.yaml
      claim: tpl-powered extraObjects handling has an accepted production-review disposition.
    - path: runs/live-kind-parity/jetstack-cert-manager-crds-enabled/receipt.yaml
      claim: The crds-enabled base passes strict two-cluster live parity.
    - path: runs/live-helm-confighub-compare/jetstack-cert-manager-crds-enabled/receipt.yaml
      claim: The crds-enabled base passes regular Helm, ConfigHub kubectl apply, and ConfigHub OCI/Argo live parity with healthy runtime.
    - path: runs/lifecycle-observations/cert-manager-eso/jetstack-cert-manager-default/receipt.yaml
      claim: Runtime lifecycle observation proves the default base when compatible external CRDs are staged.
    - path: runs/lifecycle-observations/cert-manager-eso/jetstack-cert-manager-crds-enabled/receipt.yaml
      claim: Runtime lifecycle observation proves the crds-enabled base with rendered CRDs.
  affectedVariants:
    - default
    - crds-enabled
  acceptedWarnings:
    - admission-webhook-requires-observation
    - cluster-rbac-review
    - crd-upgrade-policy
    - helm-hook-lifecycle-policy
    - unset-cpu-requirements
    - unset-memory-requirements
  variantCaveats:
    - "crds-enabled is the stronger first production-review path because it has strict live parity, ConfigHub OCI/Argo live proof, and lifecycle observation in the repo."
    - "default requires compatible external CRDs and fresh startup API observation before production use."
    - "A hardened production base may add resource requests and limits where the upstream chart supports them."
  remainingProductionBlockers: []
  nextDecision: A production support decision should choose the CRD ownership path, resource policy, webhook failure policy, and target runtime checks for the chosen base.