Target Facts And Lifecycle Skill · ConfigHub Workshop

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

Generated at: 2026-09-04T11:23:58.207Z 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.