Migrate Policy retention interfaces

docs/INTERFACE_PATTERN_MIGRATION.md

@@ -0,0 +1,19 @@
+# Policy Interface Pattern Migration
+
+Policy contributes four retention-administration sections to the Access-owned
+administration host. It does not own an independent route or shell.
+
+| Surface | Archetype | Consequence and provenance | Evidence |
+| --- | --- | --- | --- |
+| System retention | Effective-policy editor plus destructive operation | Typed values show their effective source path. Applying retention can irreversibly redact or delete eligible content and therefore requires explicit confirmation; dry-run and applied outcomes are distinguished. | `RetentionPoliciesPanel.tsx`, Core `RetentionPolicyScopeManager`, interface-pattern structural test |
+| Tenant retention | Effective-policy editor | A tenant may only narrow fields that system policy allows. Read-only authority and parent locks are explicit. | Core policy-source and blocker components |
+| Group retention | Targeted effective-policy editor | Group selection is loaded through bounded delta requests; missing target, parent lock, and write authority remain distinct states. | Target loader plus Core retention editor |
+| User retention | Targeted effective-policy editor | User labels expose only authorized account metadata; retained data itself is never returned by this administration surface. | Target loader plus Core retention editor |
+
+The retention execution result is a typed, filterable outcome table. Raw JSON
+is neither the primary policy editor nor the operator result view. The backend
+remains authoritative for policy validation, narrowing rules, destructive
+effects, redaction, and audit evidence.
+
+Contextual help uses `policy.retention` and `privacy.retention`, which resolve
+through the optional Docs module or the hosted documentation fallback.

docs/POLICY_DECISION_PROVENANCE.md

@@ -120,6 +120,13 @@ System: Allow
 When a parent disallows lower-level limits or changes, the UI should disable
 the affected controls and avoid sending those fields in the save payload.
 
+System retention execution is a separate high-consequence operation. The UI
+must distinguish dry-run evidence from an applied run, render bounded counts as
+typed rows rather than raw JSON, explain missing write authority, and require a
+destructive confirmation that names deletion/redaction and recovery
+expectations. The backend remains authoritative and records the mode plus
+bounded outcome counts in audit evidence.
+
 The shared core WebUI helper `PolicySourcePath` renders the source path shape
 for module UIs. Modules may use their own field layout, but the data contract
 should remain this shape.