Why Synced Is Not Working

UNOFFICIAL/EXPERIMENTAL

This is not a bug in GitOps. It is a boundary. A controller can apply the declared objects and still leave the operator with a missing Secret, a waiting pod, a webhook that is not ready, or a target capability mismatch.

The False Green

A rendered object-set check can pass when every desired object exists and every authored field matches.

That still does not prove:

• required Secrets or other target facts exist;
• pods reached readiness;
• controller-owned status or generated data appeared;
• no unexpected objects exist outside the desired set;
• the observation is fresh enough to trust.

The cub-scout example at confighub/cub-scout examples/helm-expt reproduces this boundary directly.

It uses a fixture where the desired objects are present, but a required Secret is absent. The result is:

object-set-matches:   PASS
prerequisites-met:    BLOCK
workloads-converged:  BLOCK

The pod reaches CreateContainerConfigError. The object-set check was not wrong; it was incomplete for the question "is this install working?"

What The Catalog Adds

helm-expt separates the proof into lanes:

render parity
-> ConfigHub upload and scan
-> local live apply
-> GitOps/OCI sync
-> cub-scout live witness
-> lifecycle observation

Each lane answers a different question. A row should only be called passed for the lane it actually passed.

What To Check

For a real install, check at least:

cub-scout receipt verify \
  --file <rendered-objects.yaml> \
  --scope namespace/<namespace> \
  --predicate object-set-matches \
  --ttl 1h \
  --fail-on any-non-pass

cub-scout receipt verify \
  --prerequisites <target-facts.yaml> \
  --scope namespace/<namespace> \
  --predicate prerequisites-met \
  --ttl 1h \
  --fail-on any-non-pass

cub-scout receipt verify \
  --file <rendered-objects.yaml> \
  --scope namespace/<namespace> \
  --predicate workloads-converged \
  --ttl 1h \
  --fail-on any-non-pass

Use Chain Of Proof for the boundary map and Current Proof Status for current evidence.