[SamSCN]

Summary

Group processing could only be switched on or off per directory (AD / Google.enableGroupProcessing), so a district couldn't, for example, manage student groups while leaving staff groups alone.

• Per-record flags ProcessGroupsAD / ProcessGroupsGoogle on New-IDBridgeSourceRecord, default $true. When a record's flag is $false, that directory's group processing leaves the person alone entirely: no adds, no removes, and no deactivate strip. It's a user-level skip rather than an empty GroupsProposed, which with Remove on would strip every group. The flags only narrow enableGroupProcessing; they can never turn it on. Get-ADUserGroupsToUpdate / Get-GoogleUserGroupsToUpdate log the skipped count at Trace, and the groups-not-processed trace ignores opted-out users.
• Templates expose it. Staff (TemplateVersion 2): $ADProcessGroups / $GoogleProcessGroups. Skyward (TemplateVersion 3) and Infinite Campus (TemplateVersion 2): per grade via AD/Google.ProcessGroups in GradeDefaultSettings / GradeOverrides, read as -ne $false so a settings block without the key stays opted in. Installed plugins need no change.
• One deactivate-strip gate that honors WhatIf. AD stripped groups on deactivate whenever enableGroupProcessingTrash was on, even with AD.enableGroupProcessing = $false. Google also required the master switch. Neither checked enableGroupProcessingWhatIf, so with Trash on, deactivations stripped groups for real in WhatIf mode, contradicting the documented "no group writes happen". Both directories now strip only when enableGroupProcessing and enableGroupProcessingTrash are on, WhatIf is off, and the user hasn't opted out. Behavior change: Trash on with WhatIf on (either directory), or with AD group processing off, no longer strips on deactivate.
• Docs: plugins.md, configuration.md, functions.md, getting-started.md, CLAUDE.md safety model.
• Release 26.10.9.0 as the last commit.

Verification

• Pester before (clean main): 252 passed, 0 failed. After: 259 passed, 0 failed (7 new cases). Against the old code, the 6 behavior cases fail and the 2 regression guards (record without the property; AD-only opt-out still processed in Google) pass. Test-ModuleManifest passes at 26.10.9.0.
• The trash gate lives in Invoke-IDBridge's execute phase, which the decide-phase suite doesn't cover. Its actual expressions were lifted from the file through the PowerShell parser and checked against all 8 Enable/Trash/WhatIf combinations × 4 flag values ($null, $true, $false, 'FALSE') for both directories.
• Not executed: a live run against AD or Google.

Not included

The shipped Invoke-PluginStaffOverride only accepts a fixed list of override Types, so the override sheet can't set these flags yet. Merge-IDBridgeOverrideData already handles them, including a sheet's 'FALSE' string.

After merge

Tag the merge commit v26.10.9.0 (or dispatch the Publish workflow), which publishes to the Gallery and creates the GitHub Release.

🤖 Generated with Claude Code