The maintained Kubara live-proof home is confighub/kubara-confighub. The Catalog retains its own packages, listings and stack composition data. The snapshot lock records the exact upstream commit, the seventeen receipt/data files the Kubara page and its readers use, and the identities of the two live executors those receipts cite. Snapshot files keep their existing paths and bytes.
Verify or refresh the snapshot
Offline integrity check against the reviewed lock:
node scripts/sync-kubara-upstream-evidence.mjs --verifyCheck that the files actually belong to the named upstream commit:
node scripts/sync-kubara-upstream-evidence.mjs --verify-upstreamThe second check fetches the GitHub tree for the immutable commit and compares Git blob identities as well as local SHA-256 digests, for the snapshot files and for the pinned executors. It also reads that commit's package.json and .github/workflows/verify.yml, requires the offline-verify job to run the four receipt and matrix gates named in the table below under their exact commands, and requires that job's check run at the commit to have passed. Missing files, changed bytes, symlinks in the upstream tree, truncated responses, a missing gate and a failed or absent upstream run all fail closed. The dedicated CI workflow runs this source check when any pinned input changes. The ordinary verify chain checks local integrity without a network dependency. An offline check alone trusts the reviewed lock; it is not a fresh upstream check.
After a reviewed upstream re-proof, update all files together:
node scripts/sync-kubara-upstream-evidence.mjs --pin <full-upstream-commit>This downloads data only. The executors are downloaded only to hash them and are never written or run here. No live lane runs. All downloaded files are validated against the source tree, and the upstream gates are checked, before writes begin. Review the resulting evidence diff, regenerate dependent Catalog/site surfaces with the pinned site timestamp, and force-add any changed receipts under runs/. Run the source check and normal repository gates before opening a pull request.
Proof limits
The pinned proof is the Kubara v0.13 four-cluster hx-app-* reference organization, recorded in August 2026. By the owner's decision of 2026-09-30 that organization is retired and frozen: it is not rerun, its receipts predate the cub 0.4 field renames, and the proof is accepted and labelled historical. proof-status.yaml records that decision, and the site labels every accepted pill from it as "retained (historical)". The current live proof is the kind lab in kubara-confighub v0.5.2, at the pinned commit: its recorded run, recorded hand-back, run on Kubara v0.16, run with a second approver, recovery after kubara bootstrap, run against ConfigHub v0.8.0, run with live status on the Release and run with service accounts. Each log was recorded with cub kubara built from a branch before its release, not with a released binary: the first three from the branches v0.2.3 released, the next two from 0.2.4-dev, the next from 0.3.0-dev, the next from the branch v0.4.0 released, the last from the branch v0.5.0 released. proof-status.yaml names the commit and the logs, and the reader test requires that commit to be the pin.
The pin is 95d4b9c18ecd4c1bfc912e39df8bd429b398d5fc, kubara-confighub v0.5.2. It moved there on 2026-10-26 from 3e9521e246fca5cd43c5cf931b463db252cca525 (v0.5.1), where it had moved earlier the same day from 60ffa2986bb7d147b98528451160824f95d4e37f (v0.5.0), where it had moved that day from bd57184d6841d253703fc2a0511432ca99545677 (v0.4.0), which had moved on 2026-10-09 from 62afd6a7ef95e854b5d1cbb3834843c0a2911d67 (v0.3.0), which had moved on 2026-10-02 from fdae8a233fec57bf2f4102b8fea43c3bf557e35e (v0.2.4), which had moved on 2026-09-30 from 86884faae853b12e552354d0b7cb898bc8df59fa (v0.2.3), which had moved from a5bbe1fd20838d162e53cd8802293420c7ae53b5 the same day. At each move every snapshot file and both executor identities were byte-identical, so only the commit changed. Integrity means these are the upstream files; it does not establish freshness or a new live run of the four-cluster proof. Existing receipt and site status rules still apply. No new live receipt was created by the pin or by the cutover below.
Cutover: the live proof leaves helm-expt
The first step (#1995) established the provenance gate while the local executor copies and three known-red gates stayed. The cutover (#1759, the Option A handoff) is now done:
- Deleted from helm-expt:
reconcile-kubara-mini-idp.mjs,audit-kubara-mini-idp-orphans.mjs,import-kubara-git-revision.mjs,run-kubara-app-release.mjs, the matrix re-derivationgenerate-kubara-platform-matrix.mjs, the release verifier and selected-organization workflow compiler that only drove those executors (verify-kubara-release-acceptance.mjs,compile-kubara-selected-org-workflow.mjs), and the helpers only the executors used (scripts/lib/kubara-protected-namespace.mjs,scripts/lib/kubara-kind-traefik.mjs,scripts/lib/mini-idp-workflow-approval.mjs). Their npm lanes and verify steps went with them. kubara-confighub carries all of them under the same paths and lane names. - The known-red register is empty.
- The site's evidence reader,
scripts/lib/kubara-site-live-evidence.mjs, stays here. It no longer runs any executor: it reads the pinned receipts and binds them to the pinned executor identities in the lock.
Where each guarantee of the retired gates lives
| Retired gate | Guarantee | Where it is enforced now |
|---|---|---|
generate-kubara-platform-matrix.mjs --self-test | The committed matrix passes the live publication gate: the mini-IDP overlay is accepted as current live, all 36 cells parse, every mini-IDP source digest verified, the faithful receipt passes, and the orphan receipt is accepted as scoped-residue clean. | Here: the site reader's matrix gate checks every one of those fields on the pinned matrix.json, and tests/kubara-site-live-evidence.test.mjs (in npm run verify) proves it rejects a rejected, partial, stale-faithful or unclean overlay. The upstream generator's own synthetic self-test is not in kubara-confighub CI; its real-data half is repeated there by --verify --all below. |
generate-kubara-platform-matrix.mjs --verify --all | Every matrix output, current and historical, is exactly what the generator re-derives from the committed receipts, and the current matrix is publishable as live (including the orphan audit accepted through the auditor's --receipt-verify). | kubara-confighub: npm run kubara-platform-matrix:verify in the offline-verify job of .github/workflows/verify.yml, which passed at the pin. Here: all nine data/kubara-platform-matrix/ files are pinned byte for byte in the lock (--verify in npm run verify), and --verify-upstream checks the upstream job ran that command and passed. |
reconcile-kubara-mini-idp.mjs --receipt-verify | The mini-IDP receipt is structurally exact and its reconcile runs share the execution fingerprint of the reconciler that verifies it. | kubara-confighub: npm run kubara-mini-idp:receipt-verify in the same job, passed at the pin. Here: the site reader counts the receipt as verified only while it is the pinned bytes, and requires the receipt's recorded reconciler digest to equal the pinned upstream reconciler; the orphan audit must name the pinned upstream auditor and reconciler and the accepted plan digest. The reader test covers each refusal. |
The orphan and performance receipts keep their other checks here unchanged: verify-kubara-mini-idp-performance.mjs --receipt-verify still runs in npm run verify, and upstream CI runs its own copy together with kubara-mini-idp:orphan-audit:receipt-verify.
What changed for the site
The reader previously compared the orphan receipt with helm-expt's own copies of the auditor and reconciler. Those copies had drifted from the ones that produced the receipts, so the page's orphan gate, and therefore its complete chain, reported the receipts as stale. Bound to the pinned kubara-confighub executors that produced and verified them, the chain is complete and consistent. Following the owner's decision, the Kubara pages say exactly that and label it frozen historical evidence, not current or live: accepted pills read "retained (historical)", the page state is historical, and the pages point to the kind lab as the current live proof. Unaccepted or inconsistent evidence still shows its warning pill. The pill rule and the proof-status checks are in scripts/lib/kubara-site-live-evidence.mjs and are covered by tests/kubara-site-live-evidence.test.mjs.
Not transferred
prepare-kubara-git-handoff.mjsstays here as an offline generator. Its self-test no longer compiles the prepared subtree through the importer; that round trip belongs to kubara-confighub, whose CI runs the importer self-test but not this preparer's.data/kubara-adoption-screenshots/and the pinneddata/kubara-release-acceptance/contract.yamlwere only read by the deleted release verifier. They remain here unchanged and are identical to the pinned commit; the contract's integrity is locked, the screenshot contract's is not.- The receipts predate the ChangeWorkflow/ChangeOrder attestation migration and the cub 0.4 field renames. The four-cluster organization is retired, so they are not refreshed; they stay pinned as historical evidence.