Add pull request template

.github/pull_request_template.md

@@ -0,0 +1,43 @@
+<!--
+Replace each HTML comment with your content. Keep section headings even
+when they don't apply — write "N/A" so reviewers can tell you considered
+the section rather than skipped it.
+-->
+
+- Resolves #<issue>
+<!-- One bullet per linked issue / RFC / upstream ticket. Use "Resolves",
+"Refs", or "Part of" as appropriate. -->
+
+## Description
+
+<!-- What changed, and why. Written for someone who has not read the diff. -->
+
+## Decisions Made
+
+<!-- Non-obvious choices and the alternatives you rejected. One bullet per
+decision: what you chose, what you didn't, why. Skip the obvious ones. -->
+
+## CRD / API Compatibility
+
+<!-- Does this change CRDs, RBAC, webhooks, status fields, or finalizers?
+Is it backward compatible with existing cluster state? Call out stored-
+version migrations, removed/renamed fields, and changes to reconciliation
+semantics. Write "N/A" only if no API surface is touched. -->
+
+## Risks and Mitigations
+
+<!-- What could go wrong in production, and what you did about it.
+Reconciler hot-loops, requeue storms, leaked finalizers, RBAC gaps,
+upgrade-in-place hazards. One bullet per risk. -->
+
+## Rollback Strategy
+
+<!-- How an operator does this safely if it goes bad. Is reverting the
+image enough? Are CRD changes reversible? Does rollback require manual
+cleanup (orphaned resources, finalizers, stuck status)? -->
+
+## Verification
+
+<!-- Concrete evidence this works. Unit/integration tests added, e2e
+output, or a manual repro against a cluster ("applied X, observed Y,
+deleted Z, status reached W"). CI-green alone is not verification. -->