Avoid production redeployment when only CI validation inputs change #5077

🤖 Generated by the Agentic Engineer

User Story

As a maintainer or agent finishing a Platform change,
I want changes that leave every production input unchanged to complete their required validation without redeploying production,
So that CI-only improvements do not occupy the deployment lane or wait on unrelated production convergence.

Evidence and hypothesis

• The protected candidate for ci(policy): avoid rerunning unrelated mutation fixtures #5065, dedc6033bb3b39eaed40a99c0f993d4581e4bf39, differs from its base b8b64944a29ff1bfdd5215def01423640b6a32d8 in exactly one file: scripts/tests/test-validate-kyverno-fixture-evaluation.sh (56 changed lines). This is the actual candidate-to-base comparison, not the PR's older file list.
• Protected CI run 39172454843 nevertheless entered Deploy to Prod at 22:51:55 UTC on 2026-10-18. It completed successfully; the completed baseline records 38m07s required feedback, 15m43s deployment and 53m00s occupied job time.
• The broad k8s change classification currently selects both validation and the merge-group production deployment. That classification intentionally includes CI regression scripts. Sharing the selector makes a validation requirement imply a production change.
• Hypothesis: distinguishing validation selection from the complete production-input change set removes unnecessary deployment work without changing which checks run or which actual production changes require deployment and acceptance. Savings are not proven yet.

Part of #4979. Related: #4569 (parallel validation scheduling, which deliberately preserves existing admission).

Acceptance Criteria

• Record the completed baseline run's feedback, deployment duration and summed occupied runner time separately. Do not call occupied time a billed-cost measurement. Baseline receipt.
• Trace and test the complete production-input closure before defining a separate selector: rendered manifests, dependency pins, publication inputs, bootstrap/deployment helpers, workflow/action definitions, authorization, and generated or embedded inputs. A filename or extension alone is not proof that an input is irrelevant.
• Add RED/GREEN regression cases showing a genuine CI-test-only change with unchanged production inputs does not select deployment, while independently mutating each production-input family still does. Include generated/embedded inputs and merge-group comparisons.
• Missing comparison data, unknown inputs or failed classification cannot silently skip deployment: require it or fail closed with a named reason.
• Preserve all existing required validation families, strict selected-job result checks, signature/trust checks, queue-membership checks, and production acceptance/heal behavior for actual deployment candidates. Do not skip checks, weaken assertions, raise timeouts or relax protected-branch gates.
• Validate an actual protected test-only candidate: every required check succeeds, production input equality is demonstrated, and deployment is intentionally unselected. Also prove a real production-input candidate still takes the complete deployment/acceptance path.
• Measure at least three comparable successful post-delivery runs against the recorded baseline, reporting feedback time and occupied runner time separately with sample limitations. Keep the outcome issue open until those observations exist.

Refinement and priority rationale

This addresses delivery lead time for every contributor, avoids needless production activity, and can release the serialized deployment lane. It is a candidate for high priority, but must be refined before Ready: map the production-input closure, identify affected fixtures and downstream consumers, and estimate end-to-end implementation, review and protected-queue proof. No savings estimate or readiness claim is assigned from this single observation.