# 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](./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).