Bring Kubara's managed add-ons into ConfigHub

1. See your platform the way ConfigHub would hold it

This takes about 15 minutes. You need the cub CLI, Kubara v0.15 or newer, and helm. You need no ConfigHub account and no cluster, and nothing changes outside the directories these commands write.

Already run Kubara? Skip init and kubara generate, and run plan and render on your Kubara work directory.

Before creating inputs: the .env file holds your Argo CD password and Git token. Keep it out of Git and shared review output.

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.

# Install the plugin release this page was checked with
$ cub plugin install confighub/kubara-confighub@v0.5.2

$ cub kubara version

# Optional: Kubara's services, with the Workshop's evidence for each chart
$ cub kubara services

# Write a Kubara config.yaml with a hub in dev and a spoke in prod
$ cub kubara init --out my-platform --services cert-manager,metrics-server,traefik --hub hub-dev:dev --spoke edge-prod:prod

# Copy the env template, then fill in the values it asks for
$ cp my-platform/.env.example my-platform/.env

# Let Kubara generate the platform, as it always does
$ kubara --work-dir my-platform --config-file config.yaml --env-file .env generate --helm

# What ConfigHub would hold: stages, bases, variants and chart evidence
$ cub kubara plan my-platform

# Each service for each cluster, as Kubara's ApplicationSets deliver it
$ cub kubara render my-platform --out my-platform-render

What you get. plan prints the stages in rollout order, a base for each component, and a variant for each cluster that runs it. For each chart it says if the Workshop Catalog checked the exact version Kubara pins. With Kubara's 3.0 catalogs, the default for Kubara v0.16, the Workshop has checked every upstream chart version they pin (#2052), so each one links its Catalog page. render writes each cluster's services as objects.yaml files, and render.json records each chart, values file and digest.

You can stop here. Open one generated objects.yaml and find its chart and values in render.json. You now have inspectable configuration; no service has been deployed. Continue to governance only when you want to store and deliver it.

init, generate and plan take seconds. The first render takes longer, because Helm fetches each chart's dependencies into a cached copy. Your work directory stays as it was. In the render, each Secret keeps its keys and loses its values.

init also writes a .gitignore that leaves out .env, **/charts/, **/Chart.lock and **/*.tgz. If one exists, init adds only the lines it lacks. Keep .env out of Git, because it holds the Argo CD password and your Git token.

To undo, delete my-platform and my-platform-render. The guide explains each step: services, init, plan and render.

After the local result: store, deliver and recover

2. Govern it: apply, handover, check, handback

These steps bring the platform into a ConfigHub organization and point Kubara's hub at approved releases. apply, handover and handback only write a script. You read the script, then you run it.

Try them on the kind lab first. It builds a Kubara hub and spoke on your laptop, and runs every step below against them. On kind, cert-manager is Degraded and Traefik is Progressing, so check exits non-zero there.

What you need. cub and ConfigHub v0.9.0 or newer. cub kubara v0.5.0 is the first release that uses service accounts, which replace the workers ConfigHub is retiring. handover.sh checks cub, jq and openssl before it changes anything. You also need a ConfigHub organization and cub auth login, with rights to create Spaces, Targets, service accounts and Channels. The hub scripts also need jq and openssl, and kubectl access that can write in the hub's argocd and argobot namespaces. The hub needs Argo CD 3.1 or newer; Kubara ships 3.5.

# Render each cluster as Argo CD will, and write apply.sh
$ cub kubara apply my-platform --out my-platform-confighub --capabilities hub-dev=<hub context> --capabilities edge-prod=<prod context>

# Read the script, then run it
$ bash my-platform-confighub/apply.sh

# Write handover.sh; it may approve dev, and prod waits for someone else
$ cub kubara handover my-platform --out my-platform-confighub --capabilities hub-dev=<hub context> --approve-stages dev

# Read the script, then run it against Kubara's hub
$ HUB_CONTEXT=<hub context> bash my-platform-confighub/handover.sh

# Each cluster runs the release its stage approved, and is Healthy
$ cub kubara check my-platform --hub-context <hub context>

# To undo handover, write handback.sh from the directory Git holds
$ cub kubara handback my-platform --out my-platform-confighub --capabilities hub-dev=<hub context> --capabilities edge-prod=<prod context>

$ HUB_CONTEXT=<hub context> bash my-platform-confighub/handback.sh

Step	What it changes	How to undo it
`cub kubara apply`	Files only: `apply.sh`, `plan.txt`, and each component's renders and rollout workflow.	Delete the `--out` directory.
`apply.sh`	ConfigHub only. It creates a component, a base Space and a rollout workflow for each Kubara component, a variant Space for each cluster, and `<prefix>-kubara-generated`. It creates no Targets and releases nothing, so the hub keeps delivering from Git.	Delete the Spaces, as shown below.
`handover.sh` steps 0 to 4	ConfigHub only. It creates `<prefix>-targets` with a Target for each cluster, and two service accounts with no role in the organization. `<prefix>-delivery`, which Argo CD pulls with, gets View and ViewChildren on each Target. `<prefix>-argobot` gets the same and EditChildren. Neither gets anything on a Space. It releases every variant stage by stage. It approves as you only in the stages `--approve-stages` names, every stage by default.	Delete the Spaces, as shown below.
`handover.sh` in a stage it may not approve	ConfigHub only. It promotes each release, prints one `cub variant approve` command for each, and exits with status 2 before it changes the hub. The hub still delivers from Git.	Nothing to undo. After the other person approves, run `handover.sh` again; it resumes the same change orders.
`handover.sh` steps 5 and 6	Kubara's hub. It stores one gateway credential, a token of `<prefix>-delivery`, lets the AppProject read the gateway, and points each routed ApplicationSet at ConfigHub. Then it installs argobot v0.2.3, which signs in with a key of `<prefix>-argobot` and hears of releases on a Channel, and waits until the newest release of each variant holds a live status. Run again, it keeps the token and the key while ConfigHub still lists them. It stops first if Argo CD would delete anything.	Run `handback.sh`.
`cub kubara check`	Nothing. It asks ConfigHub through the SDK and runs no `cub` command; it still runs `kubectl` to read the hub. With `--record`, it writes a `LiveCheck` attestation for each verdict.	`cub attestation revoke` withdraws an attestation.
`handback.sh`	Kubara's hub only. Each ApplicationSet and the AppProject read Kubara's Git again, and argobot and the gateway credential leave. ConfigHub keeps every Space and release.	Run `handover.sh` again.
`kubara bootstrap` on a handed-over hub	Kubara's hub. It writes Kubara's Git sources back into every routed ApplicationSet, so each Application syncs from Git again. It changes nothing in ConfigHub.	Run `handover.sh` again, straight away.

Pass the same --prefix and --stages to plan, apply, handover, check and handback. Each command refuses a --stages that does not name every stage once, and says which stage is wrong.

On a real platform, pass --capabilities for every cluster. A render that differs from what Argo CD runs makes handover.sh stop on its prune check.

Who approves. By default, handover.sh approves the first release in every stage, as the person who runs it. That first release holds what Git already delivers. To leave a stage to someone else, pass --approve-stages with the stages the script may approve, or none. In the other stages it stops before the hub changes, and prints the approve commands. Once they are run, run handover.sh again. It resumes the same change orders and hands the hub over.

Once a second person approves every change, run apply with --allow-authors=false, then run apply.sh again. After that, handover.sh also stops for that second approval.

If handover.sh stops halfway, fix what it names and run it again. In steps 0 to 4 the hub has not changed. In step 5 some ApplicationSets can read ConfigHub and others Git, so run it again or run handback.sh.

What check judges. A variant passes when one Application reads its latest release from ConfigHub and no Git source. It must also be Healthy, prune nothing, and keep live Secret values. Degraded or Missing fails. Progressing is "not yet": check exits non-zero, records nothing, and you run it again later.

After kubara bootstrap, run handover.sh again. Bootstrap on a handed-over hub silently hands it back to Git, and undoes the changes made in ConfigHub since handover. check then fails each variant with it still lists Git sources. Running handover.sh again is the whole recovery. Do not promote until you have run it.

Before you hand back, put in Git each change you made in ConfigHub since handover. Git undoes any change it does not hold.

To remove the platform from ConfigHub, run handback.sh first, because the hub must not read Spaces you delete. Then list the Spaces with your prefix, check the list, and delete them:

$ cub space list --where "Slug LIKE 'kubara-%'"

$ cub space delete --where "Slug LIKE 'kubara-%'" --recursive-force

After handover

Change a base once, then take the change through the stages with cub changeorder create, cub variant promote, cub variant approve and cub release publish. When Kubara generates something new, such as a newer catalog, run apply and apply.sh again. Each base that changed gets one change order to review, and changes made in ConfigHub stay. To undo a released change, release the state before it with --revision Before:ChangeOrder:<change order>.

The guide has each step: apply, handover, a change after handover, a new Kubara catalog, live status and the Healthy gate, check, handback, what each step changes and if something goes wrong.

3. Check the same platform as a Workshop stack

A Workshop stack is the same platform seen as one composition: a component for each service and a variant for each cluster. Use it to check the platform before anything runs, compose apps onto it, or publish it as OCI. Approvals and handover stay with cub kubara.

cub stack from-kubara runs cub kubara render, so the stack holds the objects Kubara's hub delivers. It needs the Workshop plugin, cub kubara v0.5.2 or later, helm, node and oras, and no account.

# Install the Workshop plugin release this page was checked with
$ cub plugin install confighub/cub-workshop@v0.6.61

# Kubara's own output as one stack
$ cub stack from-kubara my-platform --out my-platform-stack

# Check the whole stack, then what one cluster runs
$ cub stack check my-platform-stack/stack.yaml

$ cub stack check my-platform-stack/stack.yaml --cluster edge-prod

# Publish one OCI index; it checks every cluster before it pushes
$ cub stack publish my-platform-stack/stack.yaml --out oci://<registry>/<repository>:<tag>

check looks for components that conflict, CRD order, served API versions, webhooks that need a certificate, and namespaces. It ends with CHECKED or REFUSED. It is a static check, so it cannot show that a cluster runs the platform. publish refuses before it pushes anything when one cluster does not check out, and attaches each cluster's verdict to the index.

Without --out, from-kubara writes confighub/ inside the work directory. It can suggest cub stack upload --run next. That creates its own Spaces and Components, apart from the ones apply.sh creates, so give it another --space-prefix. Since Workshop v0.6.55 the prefix names each Component <prefix>-<component> as well as its Spaces, so the upload creates no bare Component such as cert-manager. You do not need an upload to govern the platform.

The Workshop README section Turn a Kubara platform into one stack has the details. For a ready-made example, cub stack sandbox kubara-platform prints the Catalog's tested images of the same three charts as Kubernetes YAML. It does not start a cluster.

Need GitOps services and the shop app? Save, change and resume a local platform using the retained kubara-gitops-shop selection. The Guide provides direct cub commands and an assistant task, with saved results and a failure case. Static composition does not establish GitOps reconciliation or application health.

Continue with a managed fleet, or a cluster in minutes

The following commands create or change ConfigHub records. First sign in to the organization you intend to use, inspect the fleet manifest, and confirm the demo Space names are available. They use the shipped fleet manifest, not the files generated above.

$ cub fleet up demo-platform

$ cub fleet age demo-platform && cub fleet status demo-platform

$ cub variant promote metrics-server-demo-dev --dry-run

If a remote step fails, inspect the records already created before retrying. Preserve existing resources; use the linked runbook for scoped cleanup.

cub cluster up --name demo --space demo-cluster

One command creates a temporary kind cluster, installs Argo CD, and wires it to a ConfigHub Space. It needs a ConfigHub account and Docker; the cluster runs on your laptop.

The composition, as evidence

Each component in a stack carries a certified-bundle receipt that names what it is and how it may be flattened, and the eight-bundle EKS inference platform is one worked example. The single composition verdict over a whole stack is specified and runs two ways today. This repository arms it as a regression gate over its own receipts. The workshop plugin's cub stack check runs it anywhere, refusing a real conflict rather than reporting one. As a gate inside the ConfigHub product it remains proposed.

4. Known limits

Read these before you run apply.sh or handover.sh on a real hub. The guide keeps the full list.

It has run on kind only. The kind lab ran it with Kubara v0.15.0 and v0.16.0, and Argo CD 3.5.2. Its latest run used cub v0.9.0 and ConfigHub v0.9.5. It has not run on a production platform.
Older releases stop working as ConfigHub retires workers. cub kubara v0.4.0 and earlier pull and report as a server worker. Write handover.sh with v0.5.0 and run it again, then delete the worker. With v0.3.0 or earlier the Healthy gate also never opens, because argobot writes where ConfigHub no longer reads.
Only the creator of a service account can issue its credentials. Issuing a token or a key takes Impersonate on the service account, which whoever created it has; organization admins need no grant. A re-run that keeps the token and the key issues nothing. When one must be issued and cannot be, handover.sh stops and names the command that grants Impersonate.
An Argo CD self-upgrade through ConfigHub is not proven. On kind, the hub's argocd Application never finishes a sync, because its Ingress gets no address. In the Kubara v0.16 run, the argo-cd release to dev did not land.
kubara bootstrap on a handed-over hub hands it back to Git. It says nothing about ConfigHub. Run handover.sh again straight after it.
Handover grants argobot more than live status needs. handover.sh gives <prefix>-argobot EditChildren on each cluster's Target. That covers the releases published to the Target: their live status, and also their labels and annotations, and withdrawing one. It reaches no Space. ConfigHub has no narrower grant for the live status alone. The token in Argo CD's Secret belongs to the other, read-only account, so it cannot write live status.
A cluster that joins later gets its Secrets without values. Your secret store must fill them.
The example index checks only the offline steps. In Workshop v0.6.61, cub config examples returns the kind lab first for "bring my Kubara platform into ConfigHub". Its entry ran init, generate and plan with the released plugin. It did not run the connected, controller or runtime steps, and points to the lab's logs for them. Maintainer review of the entry is pending.

5. The evidence behind this page

Each record below is committed and pinned. It shows only what it names.

Record	What it shows	What it does not show
Kind lab, recorded run	From scratch on kind: plan, apply, handover and check. argobot writes each variant Space's live status. prod accepts a release only once dev reports it Healthy. An image that does not exist turns dev Degraded, and ConfigHub refuses the promotion to prod.	The health verdict of `check`: the logged `check` predates it, and records a Pass for Applications that are Degraded on kind. The second-approver run below shows the verdict.
Kind lab, recorded hand-back	handback points each ApplicationSet back at Kubara's Git. Each of the 8 Applications pruned nothing and synced from Git. A replica change made only in ConfigHub went back to the value in Git, and a new Git commit reached the hub.	A production hub. Handing the hub over again ran on an earlier lab the same day; the log summarizes it.
Kind lab on Kubara v0.16	Newer Kubara catalogs reach dev and then prod as reviewed change orders. Changes made in ConfigHub, such as the argo-cd routing, stay.	An Argo CD upgrade: the argo-cd release to dev did not land on kind.
Kind lab, second approver	With `--approve-stages dev`, `handover.sh` approves dev, promotes into prod, prints one approve command for each release, and exits 2 before the hub changes. After the approvals, a rerun resumes the same change orders and hands the hub over. `check` judges health live: Degraded cert-manager and argocd fail, Progressing Traefik is not yet, and `--record` writes rejections.	Two people. The lab has one person, so it ran the approve commands itself. A production platform.
Kind lab, re-bootstrap	`kubara bootstrap` on the handed-over hub writes Kubara's Git sources back, and metrics-server returns to Git's one replica. `check` fails each variant with `it still lists Git sources`. `handover.sh` again prunes nothing, every Application reads ConfigHub, and metrics-server runs three replicas again.	A way to stop bootstrap from doing it. The recovery is a step you run.
Kind lab on ConfigHub v0.8.0	From scratch with `cub` and ConfigHub v0.8.0, on Kubara v0.16.0: `apply.sh`, `handover.sh` with argobot v0.1.8, and `check` through the SDK. `check --record` writes a Pass or a rejection for each variant it judged. prod is gated on dev's health, and a release that breaks dev is refused in prod: `Variant 'hub' is not healthy`.	A production platform. A narrower grant for argobot than Edit on each variant Space.
Kind lab, live status on the Release	From scratch with `cub` v0.8.7 and ConfigHub v0.8.11, on Kubara v0.15.0: `handover.sh` with argobot v0.1.9 and only the Target grant. ConfigHub refuses a release that dev has not synced: `has no live status for release 3 yet`. It accepts it once dev is Healthy on that release, and refuses a broken one: `release 4 is not healthy (Degraded)`. `handover.sh` run again changes nothing, and a `cub` that reports v0.8.1 is refused.	A production platform. A hub handed over with v0.3.0 and then moved: the run starts from scratch.
Kind lab, service accounts	With `cub` v0.9.0 and ConfigHub v0.9.5, on Kubara v0.15.0: the whole lab story with two service accounts and argobot v0.2.3 on a Channel. Both accounts deleted and `handover.sh` run again issues a new token and key, and argobot reports and Argo CD pulls again. `handback.sh` revokes the token and removes the key.	A production platform. A second operator without Impersonate: the run had one person.
Workshop proof, from-kubara	Real Kubara v0.16 output as one stack: six components and ten cluster renders, checked whole and per cluster. It was published to a local registry and uploaded twice to a hosted organization; the second upload wrote nothing.	A cluster. Nothing was applied, reconciled or seen healthy.

The kind-lab logs are pinned at commit 95d4b9c, the v0.5.2 release of confighub/kubara-confighub. Each was recorded with cub kubara built from a branch before its release, not with a released binary. The first three came from the branches v0.2.3 released, and the second-approver and re-bootstrap runs from 0.2.4-dev. The ConfigHub v0.8.0 run came from 0.3.0-dev, the live-status run from the branch v0.4.0 released, and the service-account run from the branch v0.5.0 released. The Workshop proof used a build from before v0.2.3, which reports 0.2.3-dev.

The commands in sections 1 and 3 were checked with the released cub kubara v0.5.2, Workshop v0.6.61, cub v0.9.0, Kubara v0.15.0 and Helm v4.1.4. That check wrote apply.sh, handover.sh and handback.sh without running them, and left the work directory unchanged.

The four-cluster reference proof is older and separate. Earlier work and Kubara and ConfigHub, explained keep it, labelled as historical.

6. Give your agent this prompt

I run a Kubara platform. Its work directory is <path>.

1. Install cub kubara v0.5.2 with: cub plugin install confighub/kubara-confighub@v0.5.2
   Then read https://github.com/confighub/kubara-confighub/blob/main/docs/user/cub-kubara.md
2. Run cub kubara plan and cub kubara render --out <new directory> on my work directory.
   Tell me the stages, the bases and variants, and which charts the Workshop Catalog
   checked at the exact version Kubara pins. Change nothing.
3. Run cub kubara apply and cub kubara handover with --out <new directory>.
   Tell me what apply.sh and handover.sh would change. Do not run either script.
4. List the guide's known limits that apply to my platform.
5. For each chart the plan marks unchecked, say so, and with my approval file it at
   https://github.com/confighub/helm-expt/issues/new?template=problem-chart.yml

Steps 1 to 4 read your files and write new directories only. Step 5 files a public issue with your approval, so an unchecked chart can get a Catalog entry with receipts.

Why hand any of this to an agent? Our committed two-round benchmark measured where agents are already strong and where they cannot be. A bare agent with a shell answered static chart questions at 96.7 percent. Twelve of eighteen questions about time, live state, and accountability needed records the agent could not produce. The toolchain carries day one; the records carry every day after. The benchmark and the full prompt live on the challenge page, and the run data is committed in data/ai-benchmark.

7. Earlier work, before cub kubara

Before cub kubara, this project brought Kubara into ConfigHub with a Node starter, a Git and OCI importer, and a four-cluster reference organization. The material stays for its detail and receipts. For a new platform, start with section 1.

Choose services with the Node starter

The starter uses four ordinary platform services and records one optional runtime image. Use the links to check each component, then change the comma-separated service list to suit your platform.

Job	Selected component	Catalog page
Certificates	cert-manager	jetstack/cert-manager 1.21.0
Cluster metrics	metrics-server	metrics-server 3.13.1
Ingress	traefik	Traefik 41.0.2
Monitoring	kube-prometheus-stack	kube-prometheus-stack 87.19.2

git clone https://github.com/confighub/kubara-confighub.git
cd kubara-confighub
npm run kubara-platform:start -- \
  --name inference-platform \
  --repository https://github.com/acme/platform.git \
  --services cert-manager,metrics-server,traefik,kube-prometheus-stack \
  --runtime-image vllm=vllm/vllm-openai-cpu:v0.27.1-arm64@sha256:e6745d7ba6610f637c6f22fc06cd730342e50245b6c46767235600483adfbbde \
  --output ../my-platform

Replace https://github.com/acme/platform.git with the HTTPS Git repository where you will keep the generated platform. The command needs Node.js. It does not contact ConfigHub Server, an OCI registry, or Kubernetes.

Website to command line: choose and inspect components here, then run the command with those exact component names. Give the generated files to your AI assistant when you want help with a change; review its file diff before running Kubara again.

Open the exact generated example · Open the smaller three-service starter

File the starter writes	Why it exists
config.yaml	The native Kubara selection: cluster, catalogs, enabled services, and ordinary settings.
source-and-intent.yaml	The Kubara source, exact component versions and packages, Catalog links, intended cluster, and checks still required.
runtime-images.yaml	The digest-pinned application or model-server images selected beside the platform. Kubara does not deploy this record, and an image is not a complete application.
README.md and checksums.txt	The next commands and hashes for every generated starter file.

In ../my-platform, review the generated .env.example, create a private .env, and replace every placeholder. Do not commit the private file. Then run kubara --work-dir . --config-file config.yaml --env-file .env generate --helm there.

Keep the generated platform in Git, or compile its exact revision into component OCI packages plus a digest-bound platform index. Neither choice needs a ConfigHub account.

Package the reviewed Git revision as OCI · Continue through ConfigHub and Argo CD · See what can be flattened

See the four-cluster result · Check the evidence · Open the technical runbook

See two applications added, promoted, released, and checked on the platform.

One adoption journey, in the user's order

The preparer, scanner, package verifier, binding lock, and receipt checks are checkpoints inside these steps. The stack check turns the pushed revision into a stack and checks it before OCI makes it immutable.

1. Choose components and wiring
Keep Kubara catalogs, config.yaml, values overlays, and service definitions.
2. Generate the platform and push it to Git
Run Kubara to generate the familiar platform, add-ons, ApplicationSets, overrides, and wiring. Then prepare, scan, commit, and push one exact portable revision.
3. Check the platform as a stack
Turn the pushed revision into a stack with cub stack from-kubara, then run cub stack check until the composition passes.
4. Import the Git revision and create OCI
Publish immutable component/config packages plus a digest-bound platform index.
5. Load the selected ConfigHub organization
Materialize the recognizable topology, apply twice, and prove zero residue in the declared scope.
6. Deploy applications
Promote, approve, release, and roll back; local Argo reconciles only the exact ConfigHub-authorized digest.

Open the complete tutorial and its checkpoints.

What we show in ConfigHub

The source-bound platform contract and familiar hub/spoke identity.
The component-first Catalog, retained versions, and selected instances.
Faithful Kubara and adapted ConfigHub delivery lanes side by side.
hx-web and Cubbychat across development, staging, and two production targets.
Curated native NeedsProvides Links, followed by the full extracted graph.
Exact-head production approval, promotion, departure, rollback, release, OCI digest history, and the visible no-auto-sync authority boundary.
The 16 journaled selector migrations, including four retained PostgreSQL PVC identities.
The 36-cell matrix: desired placement/version/departure, ConfigHub release digest, Argo observed revision/sync/health, and Kubernetes desired/ready counts remain separate; missing runtime evidence is Unknown. Today it observes 24 cells and marks 12 disabled, across 9 components and 4 clusters. See the full colored matrix and the catalog-adapter snapshots on GitHub.
The separate exact ConfigHub and scoped Argo/workload residue result.

The exact faithful, mini-IDP, performance, orphan, matrix, wiring, and six-frame GUI evidence set is complete and mutually consistent. It is frozen historical evidence: the Kubara v0.13 four-cluster hx-app-* reference organization, recorded in August 2026. That organization is retired and is not rerun, and its receipts predate the cub 0.4 field renames. The Catalog pins those receipts from confighub/kubara-confighub byte for byte in its evidence lock. The current live proof is the kind lab (examples/kind-lab/ in confighub/kubara-confighub v0.5.2, commit 95d4b9c). Its logs are the recorded run, recorded hand-back, recorded run and catalog upgrade on Kubara v0.16 and recorded run with a second approver. It also has the recorded recovery after kubara bootstrap, recorded ConfigHub v0.8.0 run, recorded run with live status on the Release and recorded run with service accounts.

Run the screenshot-free pre-capture gate before opening the browser. Publish exactly six real, source-current frames. Their atomic GUI receipt must bind the source and organization. It must also bind faithful, mini-IDP, orphan, matrix, wiring, image digests, capture times, visible identities, and claim boundaries. Never substitute placeholders or mocked screenshots.

Follow the receipt-bound GUI tour.

Make latest discoverable, not deployable: the adapted lane's mechanism

The adapted lane keeps targetRevision: latest as a discovery address but leaves automated sync off. On the automated path, mutable latest cannot race past approval, promotion, or rollback, and ConfigHub selects the exact OCI digest before Argo CD receives it. Blocking a privileged human or a manual Argo sync needs your own RBAC or admission control.

The adapted lane retains targetRevision: latest as the ConfigHub OCI discovery address, but leaves spec.syncPolicy.automated absent from every managed Application. Pinned argobot v0.1.6 runs with ARGO_SYNC_MODE=kubernetes, ARGO_NAMESPACE=argocd, and ARGO_REFRESH_TYPE=hard, so it refreshes but cannot deploy.

ConfigHub revalidates the authoritative release and submits operation.sync.revision=<ManifestDigest> with Kubernetes UID/resourceVersion compare-and-set only when no Argo operation is active. This is the governed improvement: mutable latest cannot race past approval, promotion, or rollback, while Argo remains the local reconciler.

The authority check inventories Applications across the whole cluster: all managed Applications must live in argocd, and the adapted lane permits zero ApplicationSets. Retained release-N Tags expose contiguous history, but the exact OCI ManifestDigest remains deployment authority. Client opening and closing checks plus the no-auto fence stop a rejected raced Release from deploying through this managed path. Atomic rejection of the Release record requires server-side publish preconditions.

Production approval uses the Unit slug and server HeadRevisionNum. Authoritative reads before and after must preserve the Unit ID, observed numeric head, and DataHash, and the gate must clear exactly once. That is bracketed exact-head evidence; it is not a claim that the approval API accepts a numeric compare-and-set token.

The retained fleet records 16 exact, one-time immutable-selector replacements. Its v1 history honestly retains 12 earlier reviewed-preflight triggers and four resource-failure recovery triggers; completed history is not rewritten. For every new attempt, the v2 policy requires an attempted exact-revision Argo operation to record and digest-bind the matching terminal resource failure before deletion. Every old UID/resourceVersion and reviewed selector transition is journaled; the replacement must be healthy. The four PostgreSQL StatefulSet migrations retain the same bound PVC UID and volume identity. This is an allowlisted migration contract, not broad delete authority.

Keep all the detail

Use the complete mini-IDP and maintainer runbook, importer contract, matrix and wiring evidence, and performance analysis. Kubara and ConfigHub, explained says what stays Kubara, what ConfigHub adds, and the evidence behind each benefit.

That earlier example is accepted only after a clean-checkout import into a fresh user-selected organization passes twice. The orphan count must be zero, one application must be healthy, and every published screenshot must be receipt-bound.