agent-platform release v4.7.13

Fixed

• The 3.x → 4.x upgrade migrates the storage version of the kagent CRDs, and keeps the hand-created ModelConfigs (giantswarm/agent-platform#396). A cluster that ran kagent 0.10 stores modelconfigs, modelproviderconfigs and remotemcpservers.kagent.dev at v1alpha2; the line’s kagent-crds chart declares v1alpha3 only, the apiserver refuses the CRD update (v1alpha2 was previously a storage version, and must remain in spec.versions until a storage migration …), kagent-crds never installs and the connectivity, substrate and kagent releases behind it never move (found by the migration rehearsal, giantswarm/agentlab#143). Two hook Jobs of the meta chart, as the hook identity in alpine/k8s, rendered whenever components.kagent-crds is on — with the bundled engine and, the one exception to “no hook without the engine”, through a cluster’s own Flux, so the cut-over stays “lift the bound and let Flux upgrade” on every installation: <release>-kagent-storage-version-backup (pre-install,pre-upgrade, weight -7) records every object of each of the three CRDs still stored at v1alpha2 into ConfigMap kagent-storage-version-migration in the kagent namespace (status and the server-set metadata stripped; recorded-at) and deletes those CRDs, so kagent-crds installs them at v1alpha3, then — on every run — re-points the three kinds from kagent.dev/v1alpha2 to v1alpha3 in every Helm release manifest that still names them (the release Secrets, patched in place: what helm mapkubeapis does for a removed API — Helm reads a release’s stored manifest back through the cluster’s REST mappings on each upgrade, and the 3.x connectivity release’s catalog and the kagent 0.x release’s default ModelConfig and tool-server RemoteMCPServer otherwise fail with unable to build kubernetes objects from current release manifest: no matches for kind "RemoteMCPServer" in version "kagent.dev/v1alpha2", as the lab showed); <release>-kagent-storage-version-restore (post-install,post-upgrade, weight 0) waits for modelconfigs.kagent.dev to be Established serving v1alpha3 (up to 8 min — under a cluster’s own Flux the post hooks run before kagent-crds has installed) and re-creates every recorded ModelConfig no Helm release owned at kagent.dev/v1alpha3 with name, namespace, labels, annotations and spec unchanged (the spec is identical in both versions), leaves one that is already present to its owner, fails the upgrade on any other refusal, and marks the ConfigMap restored-at so it runs once (a ModelConfig removed by hand after the cut-over must not come back). The chart-rendered ModelConfigs come back from their releases, model-manager’s from model-manager; RemoteMCPServers and ModelProviderConfigs are recorded, never restored — the 4.x charts render their own. A CRD that is absent or stores v1alpha3 is left alone: a fresh install and a second run change nothing (the ATS smoke sees the hooks do nothing). The hook identity <release>-hooks is created for the hooks’ events too (agent-platform.hooks.serviceAccountEvents composes them) and, without the engine, for those alone. make verify-kagent-storage-version asserts the pair, the scripts, the identity’s events, the engine-off render and the kagent-off render; verify-engine / verify-self carry the family in their expected hook sets. UPGRADE.md “3.x → 4.0 (the kagent line)” has the operator’s side: what comes back and from where, the downtime window, the record and when to delete it.