function Set-PersonaConditionLeaf { <# .SYNOPSIS Replaces a leaf condition's fields in place (FR-028). .DESCRIPTION Every condition-specific field (`property`, `value`, `values`, `groupObjectIds`, `roleIds`, `membershipMode`) is cleared before Fields is applied, then only the keys in Fields are set. This is not tidiness - the schema's `additionalProperties: false` on `condition` (VR-001 layer 2) rejects a stray field outright, and switching, say, a condition from `equals` (which carries `value`) to `in` (which carries `values`) would otherwise leave the old `value` behind and fail schema validation for a reason the editor caused but did not explain. `type` and `operator` are cleared and reset the same way, since a caller editing a condition typically passes both. .PARAMETER Node The leaf condition to edit (from Get-PersonaConditionNode). Mutated in place. .PARAMETER Fields The complete replacement field set for this leaf, for example: `@{ type = 'property'; property = 'Department'; operator = 'isNotNull' }`. .OUTPUTS System.Object - the same Node, mutated in place, returned for convenience. #> [CmdletBinding()] [OutputType([object])] param( [Parameter(Mandatory)] [object] $Node, [Parameter(Mandatory)] [hashtable] $Fields ) if ($null -ne $Node.PSObject.Properties['conditions']) { throw 'The target node is a condition group, not a leaf condition.' } $knownFields = @('type', 'property', 'operator', 'value', 'values', 'groupObjectIds', 'roleIds', 'membershipMode', 'caseSensitive') foreach ($key in $knownFields) { if ($null -ne $Node.PSObject.Properties[$key]) { $Node.PSObject.Properties.Remove($key) } } foreach ($entry in $Fields.GetEnumerator()) { $Node | Add-Member -NotePropertyName $entry.Key -NotePropertyValue $entry.Value -Force } $Node }