From be1c313c9018b46bd076411311aef71f696ab9d7 Mon Sep 17 00:00:00 2001
From: be0x74a <be0x74a@gmail.com>
Date: Sun, 10 May 2026 21:48:19 +0200
Subject: [PATCH 1/2] release: v0.3.1 prep (CHANGELOG, chart bump)

Promote Unreleased entries (#90 SourceNotFound distinction, #94 release-time
bench workflow, #97 source.version optional + Destination column rename) to
the [0.3.1] - 2026-05-10 heading. Bump chart version and appVersion to 0.3.1.
Refresh artifacthub.io/crdsExamples to use bare-Kind for the core ConfigMap
sources, matching the new lead form shipped in #97.
---
 CHANGELOG.md                 | 2 ++
 charts/projection/Chart.yaml | 8 ++------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 9dc07b7..d85670c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.3.1] - 2026-05-10
+
 ### Added
 
 - **Release-time bench workflow** (`.github/workflows/bench.yml`). Manually triggered (`workflow_dispatch`) against a release tag, branch, or SHA; runs the full 8-profile bench matrix on a self-hosted runner (label `bench-runner`) and persists the resulting JSON to the `bench-history` orphan branch under `bench-history/<label>.json`. The orphan branch is self-bootstrapped on first run. A markdown table of source-update / self-heal / ns-flip p99 latencies by profile is rendered into the workflow's step summary, and the bench JSON is uploaded as an artifact. `pull_request` triggers are deliberately omitted — self-hosted runners on public repos are exposed to fork-PR malicious code, so this workflow is operator-driven only. Per-PR shape-break smoke coverage continues to run on `ubuntu-22.04` via `bench-smoke.yml`.
diff --git a/charts/projection/Chart.yaml b/charts/projection/Chart.yaml
index dde4984..d3c2194 100644
--- a/charts/projection/Chart.yaml
+++ b/charts/projection/Chart.yaml
@@ -2,8 +2,8 @@ apiVersion: v2
 name: projection
 description: The Kubernetes CRD for declarative resource mirroring across namespaces.
 type: application
-version: 0.3.0
-appVersion: "0.3.0"
+version: 0.3.1
+appVersion: "0.3.1"
 kubeVersion: ">=1.32.0-0"
 home: https://docs.projection.sh
 sources:
@@ -60,8 +60,6 @@ annotations:
         namespace: tenant-a
       spec:
         source:
-          group: ""
-          version: v1
           kind: ConfigMap
           namespace: default
           name: app-config
@@ -71,8 +69,6 @@ annotations:
         name: app-config-fanout
       spec:
         source:
-          group: ""
-          version: v1
           kind: ConfigMap
           namespace: default
           name: app-config

From 169ba08c890817f6df04e2491c9792b028bf62bf Mon Sep 17 00:00:00 2001
From: be0x74a <be0x74a@gmail.com>
Date: Sun, 10 May 2026 21:51:48 +0200
Subject: [PATCH 2/2] docs: bump install/cosign examples to v0.3.1; fix v0.3.0
 misattribution
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Pre-tag documentation sweep found two classes of issue:

- Install examples in README, getting-started, security (cosign), and the
  chart README still referenced v0.3.0. Bumped to v0.3.1 to match the
  release being cut.
- docs/troubleshooting.md attributed the source.version relaxation to
  v0.3.0 in two places — incorrect, since v0.3.0 still carried the CEL
  rule (rescinded only in v0.3.1, per CHANGELOG and api-stability.md).
  Fixed by retiming one mention to pre-v0.3.1/v0.3.1 and rephrasing the
  other to a present-tense, version-neutral statement.
---
 README.md                   | 4 ++--
 charts/projection/README.md | 2 +-
 docs/getting-started.md     | 4 ++--
 docs/security.md            | 4 ++--
 docs/troubleshooting.md     | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/README.md b/README.md
index 046c4ac..245a5fd 100644
--- a/README.md
+++ b/README.md
@@ -115,14 +115,14 @@ Need to mirror into many namespaces from one source? Use `ClusterProjection` (cl
 
 ```bash
 helm install projection oci://ghcr.io/projection-operator/charts/projection \
-  --version 0.3.0 \
+  --version 0.3.1 \
   --namespace projection-system --create-namespace
 ```
 
 ### `kubectl apply`
 
 ```bash
-kubectl apply -f https://github.com/projection-operator/projection/releases/download/v0.3.0/install.yaml
+kubectl apply -f https://github.com/projection-operator/projection/releases/download/v0.3.1/install.yaml
 ```
 
 Then create your first `Projection`:
diff --git a/charts/projection/README.md b/charts/projection/README.md
index 383d0d4..4531ee5 100644
--- a/charts/projection/README.md
+++ b/charts/projection/README.md
@@ -65,7 +65,7 @@ Override the image for local / air-gapped deployments:
 helm install projection charts/projection \
   --namespace projection-system --create-namespace \
   --set image.repository=my-registry/projection \
-  --set image.tag=v0.3.0
+  --set image.tag=v0.3.1
 ```
 
 ## Upgrade
diff --git a/docs/getting-started.md b/docs/getting-started.md
index b1276eb..248d42a 100644
--- a/docs/getting-started.md
+++ b/docs/getting-started.md
@@ -14,14 +14,14 @@ This walks through installing the `projection` operator and creating your first
 
 ```bash
 helm install projection oci://ghcr.io/projection-operator/charts/projection \
-  --version 0.3.0 \
+  --version 0.3.1 \
   --namespace projection-system --create-namespace
 ```
 
 ### Option 2 — `kubectl apply`
 
 ```bash
-kubectl apply -f https://github.com/projection-operator/projection/releases/download/v0.3.0/install.yaml
+kubectl apply -f https://github.com/projection-operator/projection/releases/download/v0.3.1/install.yaml
 ```
 
 Either way, verify the operator is healthy:
diff --git a/docs/security.md b/docs/security.md
index 449dfc7..f19f5fd 100644
--- a/docs/security.md
+++ b/docs/security.md
@@ -347,7 +347,7 @@ This is the same design point as the [non-aggregation choice](#why-projection-cl
 Release images are pushed to `ghcr.io/projection-operator/projection` and **cosign-signed** with GitHub's OIDC keyless workflow. Verify before pulling:
 
 ```bash
-cosign verify ghcr.io/projection-operator/projection:v0.3.0 \
+cosign verify ghcr.io/projection-operator/projection:v0.3.1 \
   --certificate-identity-regexp "https://github.com/projection-operator/projection/.github/workflows/.*" \
   --certificate-oidc-issuer https://token.actions.githubusercontent.com
 ```
@@ -355,7 +355,7 @@ cosign verify ghcr.io/projection-operator/projection:v0.3.0 \
 The Helm chart is published to `oci://ghcr.io/projection-operator/charts/projection` and signed with the same workflow:
 
 ```bash
-cosign verify ghcr.io/projection-operator/charts/projection:0.3.0 \
+cosign verify ghcr.io/projection-operator/charts/projection:0.3.1 \
   --certificate-identity-regexp "https://github.com/projection-operator/projection/.github/workflows/.*" \
   --certificate-oidc-issuer https://token.actions.githubusercontent.com
 ```
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index 5032826..e73fe59 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -73,7 +73,7 @@ Things that can cause it:
 
 #### Sub-cause: unpinned version with multiple served versions
 
-The v0.3.0 SourceRef permits omitting `source.version` for any group, including core (`kind: ConfigMap` alone is valid; the operator resolves to `v1` via the RESTMapper). The RESTMapper resolves the omitted version through `RESTMapping(GroupKind)`, which returns the *preferred* version. For core resources the preferred version is always `v1`, so the resolved GVR is stable in practice. The pitfall is on **CRDs with multiple served versions**: if the source CRD has more than one served version and either declares no preferred or its preferred isn't the one that holds your data, you'll see `SourceResolutionFailed` (no mapping for the picked version) or, more confusingly, a successful resolve onto the wrong version with subsequent `SourceFetchFailed` because the data lives on a different served version.
+The SourceRef admission permits omitting `source.version` for any group, including core (`kind: ConfigMap` alone is valid; the operator resolves to `v1` via the RESTMapper). The RESTMapper resolves the omitted version through `RESTMapping(GroupKind)`, which returns the *preferred* version. For core resources the preferred version is always `v1`, so the resolved GVR is stable in practice. The pitfall is on **CRDs with multiple served versions**: if the source CRD has more than one served version and either declares no preferred or its preferred isn't the one that holds your data, you'll see `SourceResolutionFailed` (no mapping for the picked version) or, more confusingly, a successful resolve onto the wrong version with subsequent `SourceFetchFailed` because the data lives on a different served version.
 
 Diagnose:
 
@@ -159,7 +159,7 @@ If you see `SourceNotResolved`, the real failure is on the `SourceResolved` cond
 
 The apiserver rejected the spec via CEL validation rules on the CRD. The CR either never created (you'll see this as a `kubectl apply` error) or, in the rare case where CEL validation is bypassed, the controller surfaces it as a runtime `DestinationWritten=False reason=InvalidSpec` event. Either way, the cause is one of two structural mistakes:
 
-> Pre-v0.3 SourceRef carried a CEL rule `size(self.group) != 0 || size(self.version) != 0` that rejected `kubectl apply` for any Projection or ClusterProjection with both `source.group` and `source.version` empty. v0.3 drops that rule — `source.version` is now optional for any group, including core. Manifests with explicit `version: v1` continue to validate; `kind: ConfigMap` alone now works too. Old runbooks mentioning an `InvalidSpec` admission error from `source must specify version when group is empty` apply only to pre-v0.3.
+> Pre-v0.3.1 SourceRef carried a CEL rule `size(self.group) != 0 || size(self.version) != 0` that rejected `kubectl apply` for any Projection or ClusterProjection with both `source.group` and `source.version` empty. v0.3.1 drops that rule — `source.version` is now optional for any group, including core. Manifests with explicit `version: v1` continue to validate; `kind: ConfigMap` alone now works too. Old runbooks mentioning an `InvalidSpec` admission error from `source must specify version when group is empty` apply only to v0.3.0 and earlier.
 
 #### 1. ClusterProjection.destination with both `namespaces` AND `namespaceSelector` set