UNOFFICIAL/EXPERIMENTAL
Variant promotion runs in ConfigHub Server. cub variant promote clones a Unit and promotes it server-side. The catalog records receipts for maintained variants, and older watch rows remain visible until their tests are rerun.
The variant-promotion-closeout surface turns that column into an actionable queue: for every variant it says whether cub variant promote is ready to run now, watch-grade pending receipt rerun, or blocked by a proof prerequisite, with the exact next command or fix and the owner who has to act.
How to read it
| Owner class | Meaning | What to do |
|---|---|---|
run-proof | A server-side clone exists and the base has ConfigHub upload proof (or a prerequisite ConfigHub proof can run); only the promote receipt is missing or stale. | Run or rerun the listed cub variant promote proof and record the receipt. Engineering/CI, no model change. |
catalog-modeling | Needs catalog/model work before promotion is meaningful. | Model the base first, then promote. |
not-applicable-if-any | Promotion does not apply to this variant. | Nothing. |
| Readiness | Meaning |
|---|---|
ready-to-run | Clone exists; run the promote proof now. |
watch-grade | Basic promote proven on an old receipt; rerun on ConfigHub v0.1.80 or newer to prove the changeset add-new-units path. |
blocked-needs-confighub-proof | No ConfigHub upload proof yet, so there is no clone to promote. Run the ConfigHub proof lane first. |
Why this matters
It separates the promotion backlog into three very different kinds of work:
- A large
run-proofqueue - variants users can promote today; finishing them is recording or refreshing receipts, not building a new promotion model. The summary lists a representative set of exact commands. - A watch-grade rerun queue - receipts recorded before the ConfigHub v0.1.80 server fix still show the fallback path. They stay watch until rerun.
- A residual
blocked-needs-confighub-proofset - variants that need the upstream ConfigHub proof before promotion is even possible.
So the remaining non-proven promotion cells are mostly a receipt-refresh queue, not unsolved product work. The authoritative per-variant status is variant-promotion/status.csv; this surface adds the readiness, owner class, clone-exists, and proof-refresh triage on top of it.
Boundaries
Read-only. It lists promote commands but does not run them - promotion is a deliberate ConfigHub-server action. A watch-grade row is a recorded decision (mechanics proven, old receipt still used the fallback), never silently rounded up to proven. The surface regenerates from variant-promotion/status.csv.