helm-catalog Org, Wave 1

Generated by scripts/sync-helm-org.mjs --sync against org 'bd84a856-3b16-4446-b490-56ff40db0107'.

• planned: 21 base Space(s)
• created: 3
• already present: 18
• units in org (planned spaces): 449
• stopped early: no

One Space per (chart, version, base variant) base variant, immutable; labels carry Component, Variant, ChartVersion, HookRoute, CrdRoute, SecretRoute, RouteDisposition from committed catalog data. Rows in wave1.csv.

Exhibit finding: promote and same-map departures (2026-07-03)

Built live while creating the promotion-interplay exhibit (vault demo base + dev/staging/prod). Field-level departures (replicas 2, replicas 3) merged cleanly with two base releases delivered as annotation keys: UpgradeUnit revisions in staging and prod, departures intact. Dev's departure edited the statefulset's annotations map - the same map the releases wrote to. On that unit, cub variant promote:

• reported Success: 1 unit(s) each time,
• advanced the unit's UpstreamRevisionNum to the base head,
• created no new revision and delivered none of the base's annotation keys,

across three consecutive base releases. The environment reads as caught up while permanently missing the releases on that map, until someone reconciles by hand (dev carries two explicit reconcile commits, which is the exhibit's teaching move). Departures-win may be the intended policy; the silence is the finding. Not filed upstream yet per the evidence-threshold rule; recorded here.

Also observed while building: set-env-var no-ops (with success output) when the variable is not already present in the pod spec; and Config data changed is a substring of Config data not changed, so scripted greps must match the full line.

Live delivery leg + sketches (2026-07-03)

The hooks exhibit's claim ran live from this org: the fixture published once to the org's OCI registry, pulled by Argo CD, Flux, and the no-controller direct applier on a throwaway cub-lk rig - hook Job observed completing under each, all three legs pass (runs/oci-hook-delivery-proof/receipt.yaml, rig hx-ocihook-20260703-k3m, cleaned after). The CRD-ordering contract was re-proven the same session: bundle-order apply fails with the named error, CRD-first-with-wait succeeds (runs/crd-ordering-gap/receipt.yaml, watch by design - the gap is the finding).

Sketches of the unbuilt (the #4369-shaped entities, expressed in today's primitives, same move as the recipe unit): render-record unit + one exemplar rendered-from-recipe Link in hashicorp-vault-demo-base; seven addressable LifecycleRoute units in route-sketch-kube-prometheus-stack, each honestly automatic: false with evidence pointers.

Quota correction: cloned variant spaces DO carry links (they appear asynchronously after clone; an earlier count read zero). Org total measured at 977/1,000 after the sketches - 23 headroom. Render provenance therefore ships as one exemplar Link, not one per unit; further trees need quota room or a raise.

Gate-scope fix (2026-07-03, later the same day)

The maintainer spotted render-record wearing an unapprovable approval gate. Root cause: both platform filters selected every platform trigger (Space.Slug = 'platform'), so the vet-only baseline also dragged require-approval onto all 27 consuming spaces - an approval gate with no human workflow behind it, which doctrine #8 calls a lie in the UI. Fix, live and in the builder: helm-catalog-checks now excludes vet-approvedby; all consumers refreshed; hashicorp-vault-env-prod (which had inherited the baseline through its template) rewired to helm-catalog-prod-gates. End state verified: approval gates on exactly the four production Spaces (redis-prod, fleet-prod-us, fleet-prod-eu, vault-env-prod); none anywhere else; sketch units clean. The builder now wires prod filters explicitly (wireProdGates) because variant create copies the template's TriggerFilterID.

The #4697 upstreaming pattern, reproduced (2026-07-03)

A colleague's rollout plan (confighubai/confighub#4697) sets env vars directly on staging/prod first, then "upstreams" them to bases with confighubplaceholder. We reproduced that exact sequence on the vault tree (staging departs with CONFIGHUB_IDP_AUDIENCE=staging-real-audience; the base later adds the same var as confighubplaceholder plus a second, unconflicted CONFIGHUB_IDP_ISSUER; promote staging twice):

• The plan works. The placeholder did not clobber staging's real value, and the unconflicted issuer flowed in as a real UpgradeUnit revision while the conflicted audience entry stayed local. Container env merges entry-by-entry (union, local entry wins on conflict) - unlike the annotations map, which we earlier observed losing wholesale (downstream map kept, upstream keys dropped). Merge behaviour differs by structure.
• The conflict resolution is still silent. The first promote reported Success, advanced UpstreamRevisionNum, created no revision; nothing records that placeholder-vs-real was decided. Wanted here, invisible always.
• vet-placeholders gated the base the moment it carried the placeholder - the guardrail that a placeholder can never reach a cluster. By design.
• Promote propagates new base units downstream (the base's render-record sketch was created into staging, links copied) - expected inheritance, with link-quota side effects worth knowing at 977/1,000.
• CLI correction recorded: set-env upserts env vars; set-env-var only mutates existing ones (our earlier "cannot add" note was the wrong function).