# Kubara Wiring and Platform Evidence This page is the entry point for generated evidence about the current Kubara v0.13.0 four-cluster platform. The two primary views answer different questions: - [effective-render wiring](../../../data/kubara-wiring/summary.md) maps what the rendered platform objects provide and need, including the hub Argo CD ApplicationSet joins to its four cluster registrations; - [component × cluster matrix](../../../data/kubara-platform-matrix/summary.md) maps the selected component versions and intended placement across the hub and three spokes, while leaving unobserved live fields explicitly unknown. To start in ConfigHub rather than in these files, switch to the `Kubara` organization, filter Spaces by `StartHere=true`, open `hx-platform`, and then open `platform-contract`. Its metadata links to the public [buyer and adoption journey](https://confighub.github.io/helm-expt/site/kubara.html), [component-first Catalog](https://confighub.github.io/helm-expt/site/charts/), [36-cell matrix](https://confighub.github.io/helm-expt/data/kubara-platform-matrix/matrix.html), and [full wiring graph](https://confighub.github.io/helm-expt/data/kubara-wiring/graph.html). The adjacent `component-catalog-coverage` Unit makes the full Catalog promise and its evidence visible in ConfigHub: `CatalogComponents=103`, `CatalogVersions=130`, `KubaraSelections=18`, and `Retention=AdditiveOnly`. Its payload is the exact passing coverage receipt. It is not a substitute for browsing every retained version natively in this platform organization: `component-catalog-selection` and the native Components view show the exact versions selected by this platform, while `URL-Catalog` opens the complete component-first Catalog. The GUI itself groups the selected Kubara platform components under `Owner=KubaraGeneral`; the faithful Kubara Argo definition under `Owner=KubaraBootstrap`; the adapted cluster-local Argo runtime under `Owner=ConfigHubBootstrap`; argobot under `Owner=ConfigHubDelivery`; and hx-web plus cubbychat under `Owner=ConfigHubApplications`. Exact versions, deployable or configuration surfaces, base or target variants, definition or instance lineage, hub or spoke placement, and delivery lane are therefore searchable without collapsing the faithful and adapted Argo identities. The split is intentional. A committed render can prove selected desired state and visible dependency contracts; it cannot prove that a controller reconciled them. A live receipt can fill observed version, sync, and workload fields only when it records those fields for an exact component and cluster. There is also a deliberate GUI/evidence split. ConfigHub governs the desired-only platform matrix. The mini-IDP contract calls for exactly 25 curated operational `NeedsProvides` Links; the exact live receipt and orphan audit decide whether those Links are current in the selected organization. The receipt-aware public matrix and complete extracted wiring graph are linked evidence views; they are not presented as native live ConfigHub observations. ## Primary: Kubara v0.13.0 current platform The source corpus is the 13-instance [current effective-render receipt](../../../data/kubara-effective-renders/current-platform/receipt.yaml): one Argo CD instance on `hx-app-dev`, cert-manager and Traefik on all four clusters, and External Secrets, Homer, kube-prometheus-stack, and Metrics Server on the hub. Generation verifies reviewed chart archives and renders every instance twice. The generated bytes match the committed v0.13.0 example renders; the offline verifier checks all source and output checksums. The wiring extractor records rendered objects and CRDs, Kubernetes references, selectors, controller-declared Secret outputs, external inputs, service-DNS endpoints, target-cluster prerequisites, Helm hooks, and Argo ApplicationSet links to AppProjects, Git sources, and cluster registrations. Its statuses keep the evidence boundary visible: - `resolved-rendered`: a matching object or CRD is in the same cluster render; - `resolved-runtime`: a rendered controller or hook contract declares the output, but materialization is not observed; - `target-prerequisite`: a well-known cluster object is outside the render; - `optional-unprovided`: an optional reference or zero-match ApplicationSet selector has no rendered provider; - `external`: the input is intentionally outside the Kubernetes object set; - `unresolved`: the per-cluster aggregate render has no matching provider declaration. Open the [colored accessible wiring table](../../../data/kubara-wiring/graph.html), or consume [graph.json](../../../data/kubara-wiring/graph.json) and [edges.csv](../../../data/kubara-wiring/edges.csv). The full graph preserves every extracted rendered, runtime-declared, external, optional, prerequisite, and unresolved relationship. After an accepted mini-IDP run, the ConfigHub GUI must contain the smaller deterministic set of 25 `NeedsProvides` Links for operational navigation. Those Links cover the important consumer-to-provider paths without pretending that every extracted fact is an independently managed GUI edge. To verify them natively, open `hx-web-dev/hx-web-deployment` and select its **Links** tab: `needs-platform-binding` must appear beside the normal `UpgradeUnit` lineage. Then open `hx-web-platform-dev/hx-web-platform`; its **Links** tab must show the cert-manager and Traefik requirements. This exact Unit-to-Links route is the receipt-bound GUI wiring checkpoint; the public graph remains the complete render-derived evidence view. The current [colored accessible platform matrix](../../../data/kubara-platform-matrix/matrix.html) contains 36 cells: seven deployable platform roles plus hx-web and cubbychat across four clusters. It distinguishes 13 rendered platform instances, three hub-managed spoke Argo cells, the two applications on every target, and 12 platform cells disabled by the current Kubara config. Selected versions are exact. The separate [faithful-lane summary](../../../data/kubara-faithful-hub-spoke/summary.md) records the unchanged hub-and-spoke topology and its selected cert-manager witness. It is current proof only when its generated-file count and digest match the current Kubara hand-off; the [checkpoint ledger](checkpoints.md) reports that decision. The source-current mini-IDP receipt now supplies all 36 runtime observations; the public matrix may use them only after its generator binds that exact receipt and passes. Normal values overlays are listed as declared configuration, not mislabeled as runtime departures. Machine-readable outputs are [matrix.json](../../../data/kubara-platform-matrix/matrix.json) and [matrix.csv](../../../data/kubara-platform-matrix/matrix.csv). The desired 36-cell contract is governed in ConfigHub as `hx-platform/platform-matrix`. The public files above are regenerated after the mini-IDP receipt. Each cell keeps desired placement, selected version, and departure separate from the exact ConfigHub release digest; Argo observed revision, sync, and health; and Kubernetes desired/ready workload counts. A missing observation remains `unknown`, and a disabled selection is `NotApplicable`; ConfigHub desired state alone never becomes a fabricated live result. The sync field is explicitly **Argo sync**. ConfigHub state is represented by the governed Unit revision, release, and exact OCI manifest digest instead of being mislabeled as controller health. ## Secondary: historical v0.12.0 evidence The former v0.12.0 one-cluster render and adapted ConfigHub fleet receipts are retained for comparison, not merged into current cells: - [historical effective renders](../../../data/kubara-effective-renders/historical-v0.12.0/test-cluster/README.md); - [historical wiring graph](../../../data/kubara-wiring/historical-v0.12.0/summary.md); - [historical component × cluster matrix](../../../data/kubara-platform-matrix/historical-v0.12.0/summary.md). That older live proof used ConfigHub-owned Argo CD and adapted variant/OCI delivery. It remains useful evidence of observed behavior at its recorded time, but it does not establish current v0.13.0 state or faithful Kubara Git/ApplicationSet delivery. ## Commands ~~~sh # Refresh current effective renders (Helm downloads; no cluster write) node scripts/generate-kubara-effective-renders.mjs --generate --profile current # Verify and regenerate the current derived views offline node scripts/generate-kubara-effective-renders.mjs --verify --profile current node scripts/generate-kubara-wiring.mjs --generate --profile current node scripts/generate-kubara-wiring.mjs --verify --profile current node scripts/generate-kubara-wiring.mjs --self-test node scripts/generate-kubara-platform-matrix.mjs --generate --profile current node scripts/generate-kubara-platform-matrix.mjs --verify --profile current node scripts/generate-kubara-platform-matrix.mjs --self-test # Regenerate or verify both current and historical profiles node scripts/generate-kubara-effective-renders.mjs --generate --all node scripts/generate-kubara-effective-renders.mjs --verify --all node scripts/generate-kubara-wiring.mjs --generate --all node scripts/generate-kubara-wiring.mjs --verify --all node scripts/generate-kubara-platform-matrix.mjs --generate --all node scripts/generate-kubara-platform-matrix.mjs --verify --all ~~~ Only effective-render generation uses the network, to download exact Helm dependencies into a temporary working directory. These commands make no ConfigHub, Kubernetes, or Git writes.