- effective-render wiring maps what the rendered platform objects provide and need, including the hub Argo CD ApplicationSet joins to its four cluster registrations;
- component × cluster matrix 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, component-first Catalog, 36-cell matrix, and full wiring graph. 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: 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, or consume graph.json and 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 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 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 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 and 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:
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
# 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 --allOnly 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.