Historical extension selection qualification snapshot

This page records implementation and isolated-instance evidence collected for the catalog-selection changes. The linked receipt.json is historical qualification evidence, not a Kajiya promotion receipt; this page does not announce that the receipt-backed 1.3.0 release catalog route is enabled. For the current publishing boundary, see Immutable publication.

The evidence package is in the Kamiwaza repository at commit 3604f3616c7cb74f03ffdcc9d9449ed211a80eaa, committed 2026-09-16 15:02 UTC. It records a full matrix against Core source commit f19983b8a778015b9547f76820b75c4e3a15b2a7 (committed 2026-09-16 14:20 UTC) and a later runtime checkpoint at 82a81921f8a4152c0f404ad97f51fbf274079229 (committed 2026-09-16 14:50 UTC). All cases use simulated Core identities and do not qualify released 1.3.0 binaries.

The implementation snapshot summarized here was exercised on an isolated full Kamiwaza installation with k0s/KKS, PostgreSQL, Keycloak, SpiceDB, the normal API/frontend, and task-owned Moto catalog storage. No production Cloudflare catalogs were written.

The installed candidate uses simulated canonical Core identities 1.3.0, 1.3.1, and 1.4.0. These are actual instance/API/browser/workload tests, not tests of released binaries bearing those versions or certification of those combinations.

Automated regression coverage

• Combined Garden, semantic-version, database, Istio routing, setup/audit and route-auth coverage: 4,316 passed, 8 skipped.
• SDK extension suite: 2,303 passed, one BSD-sed platform skip.
• Shared-workflow contracts: 233 passed. Active Kajiya workflow contracts: 38 passed, plus 8 baseline identity tests. Deploy baseline/publication tests: 147 passed, plus 20 tenant namespace contract tests.
• Focused frontend deployment/selection suites: 106 passed before final review; final garden component suite: 18 passed. Production webpack build passed.
• Shared SemVer corpus covers numeric ordering, prereleases, build identities, malformed identities, and legacy normalization consistently across Core/SDK/Deploy.
• Canonical migration 20260916_016 adds durable catalog state and widens template version storage. SQLite initialization is separately exercised.

Working-instance cases

Simulated Core	Shipped fixture	Latest compatible fixture	New extension
1.3.0	0.3.0	0.7.0	1.0.0
1.3.1	0.4.0	0.8.0	1.1.0
1.4.0	0.5.0	0.9.0	1.1.0

Each case exercised availability refresh without selection changes, explicit updates, exact update-all preview/confirmation, atomic stale-preview rejection, baseline selection rollback, separate Add, deployment of selected exact artifacts, and removal without deleting an existing deployment. Existing workload UIDs, specs, resolved image digests, and HTTP version responses were compared.

Additional executed checks include persistent selections across Core restarts, real catalog outage with retained availability, immutable SDK publication under conditional-write conflicts, rejection of payload/digest rewrites, nonadmin 403s, terminal withdrawal after omission/republication, and admin-only governance changes. The actual PostgreSQL barrier test checks selection/overlay admission ordering in an isolated schema and removes that schema afterward.

The real UI exercised Update, Choose version/baseline rollback, Add, and confirmed Update all. The read-only account sees selected/latest state without mutation controls. Release notes are omitted. Legacy/imported duplicate version labels carry distinct provenance and identity.

Existing-deployment recovery was exercised through Core's internal recovery path: a deployment originally on 0.9 was recreated while the installation selection was 0.5. It retained its database identity, frozen runtime-artifact hash, exact image and HTTP version while receiving a new Kubernetes workload UID. This is an internal recovery test; there is no public restart endpoint implied by it.

Recorded evidence checkpoints

The fresh offline installation and repeated three-version matrix passed. The matrix used the Core source commit documented above. Subsequent review fixes received targeted live checks and source-hash verification. Kamiwaza retains each checkpoint separately, together with a machine-readable qualification evidence file (receipt.json). Final runtime checkpoint 82a81921f8a4152c0f404ad97f51fbf274079229 verifies 44 runtime/schema files and 20 frontend files, with targeted routing, failure rollback, authorization, migration and legacy-refresh checks. All 15 proof workloads remained unchanged; all 24 deployments were ready. The full matrix is not relabeled as a later-commit run. Credentials, tokens and private database backups are excluded from those artifacts.

Known validation limits

These tests exercise purpose-built extension fixtures on an isolated instance. License enforcement was disabled in the isolated test installation. These tests do not certify third-party extension behavior, data migrations, or actual released Core builds. The publisher preserves immutable catalog payloads and uses digest-qualified artifacts; registry operators must retain those artifacts.