Target Facts And Lifecycle Skill

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

UNOFFICIAL/EXPERIMENTAL

Use this skill when a base depends on cluster state that is not produced by the rendered object set.

Common target facts:

existing Secrets;
existing CRDs;
APIService aggregation readiness;
webhook serving certificates;
storage classes and PVC behavior;
Kubernetes topology, such as a minimum number of schedulable nodes;
generated runtime state that must be staged or observed.

Route

Check the base variant:

open recipes/<repo>/<chart>/<version>/variants/<base>/variant.yaml

Check the package target-fact support:

open packages/<repo>/<chart>/<version>/installer.yaml

Check whether the prerequisite is already visible in generated status:

open data/status-dashboard/summary.md
open data/secret-lifecycle/summary.md
open data/lifecycle-boundary/summary.md
open data/apiservice-coverage/summary.md

If the prerequisite changes rendered Kubernetes objects, create a new cub installer base and rerun render parity.

If the prerequisite is target state, record it as a target fact, staging step, lifecycle observation, or explicit refusal.

Target Topology

Target topology means Kubernetes scheduling and platform behavior. For example, Consul secure mesh needs three schedulable Kubernetes nodes because its server pods use anti-affinity and quorum. That is not a ConfigHub worker requirement. ConfigHub remains workerless from the target cluster's point of view.