feat: add mutation trees in kyverno-json

Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>

proposals/kyverno-json-mutations-trees.md

@@ -0,0 +1,84 @@
+# Kyverno Design Proposal - Mutations in kyverno-json
+
+Created: February 13th, 2024
+Author: [Charles-Edouard Brétéché](https://github.com/eddycharly)
+
+# Table of Contents
+
+- [Table of Contents](#table-of-contents)
+- [Overview](#overview)
+- [Definitions](#definitions)
+- [Motivation](#motivation)
+- [Proposal](#proposal)
+- [Implementation](#implementation)
+- [Migration (OPTIONAL)](#migration-optional)
+- [Drawbacks](#drawbacks)
+- [Alternatives](#alternatives)
+- [Prior Art](#prior-art)
+- [Unresolved Questions](#unresolved-questions)
+- [CRD Changes (OPTIONAL)](#crd-changes-optional)
+
+# Overview
+
+Kyverno-JSON supports validation with [assertion-trees](https://kyverno.github.io/kyverno-json/latest/policies/asserts/).
+
+This KDP is about supporting mutations, potentially with a construct called _mutation-trees_.
+
+# Definitions
+
+Make a list of the definitions that may be useful for those reviewing. Include phrases and words that Kyverno users or other interested parties may not be familiar with.
+
+# Motivation
+
+- Support mutations in kyverno-json policies
+
+# Proposal
+
+This provides a high level overview of the feature.
+
+- Given an input object and a mutation policy, applying the policy to the input object would eventually result in a new object
+- The policy should describe the expected object changes and this description should be done using the yaml syntax
+- Such a policy should rely on a generic term called mutation-trees
+
+As we start with an initial object, we can define a mutation by operation and value:
+- operations: merge or replace
+- values: another object (or `null`)
+
+We need to pay attention to the identity mutation. Ideally, an object could represent a mutation, if we start with an empty object and apply the mutation corresponding to the object we want, we should have the expected object in return.
+Applying an object to itself should result in the same object.
+
+# Implementation
+
+This is the technical portion of the KDP, where you explain the design in sufficient detail.
+
+The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+
+## Link to the Implementation PR
+
+# Migration (OPTIONAL)
+
+This section should document breaks to public API and breaks in compatibility due to this KDP's proposed changes. In addition, it should document the proposed steps that one would need to take to work through these changes.
+
+# Drawbacks
+
+Why should we **not** do this?
+
+# Alternatives
+
+- What other designs have been considered?
+- Why is this proposal the best?
+- What is the impact of not doing this?
+
+# Prior Art
+
+Discuss prior art, both the good and bad.
+
+# Unresolved Questions
+
+- What parts of the design do you expect to be resolved before this gets merged?
+- What parts of the design do you expect to be resolved through implementation of the feature?
+- What related issues do you consider out of scope for this KDP that could be addressed in the future independently of the solution that comes out of this KDP?
+
+# CRD Changes (OPTIONAL)
+
+Does this KDP entail any proposed changes to the core CRD or any extensions? If so, please document changes here.