Bau-Plan für die M1-Polish-Lücke: heute lehnt evaluatePolicy() jeden
destructive-Call ab weil settingsFor() hardcoded { allowDestructive: [] }
zurückgibt. In POLICY_MODE=enforce würde das alle User von destructive
Tools aussperren. Bisher kein Problem — es gibt keine destructive Tools
in der Registry. Sobald das erste kommt, greift dieser Plan.
Kernentscheidungen:
- Scope: per-SPACE, nicht per-User. Passt zum Space-scoped-data
model; ein Admin opt-in'd, alle Members des Spaces profitieren.
- Authority: Server-authoritative. Nicht in Dexie. JWT-gated
PUT, Role-Check (nur owner/admin dürfen ändern), RLS.
- Storage: eigene Tabelle mana_spaces.space_policy_preferences
plus append-only space_policy_audit für Diff-Tracking. NICHT
JSON-Column auf spaces — typisiert, indexierbar, mehr Raum für
spätere per-Space-Rate-Limits etc.
- Fail-closed: wenn mana-mcp apps-api nicht erreicht, wird
destructive geblockt. 30s TTL-Cache, kurz genug für Revoke-Speed.
- Acknowledgement enforced at API: PUT verlangt acknowledged:true
wenn neue Tools zur Liste. Anti-Click-Through by construction.
Inkludiert:
- Schema + RLS (Postgres)
- GET/PUT/audit-GET + interner service-key-GET
- SpacePolicyClient-Pattern in mana-mcp (wie MasterKeyClient)
- UI /s/:space/settings/ai-policy mit Audit-Section
- Metriken-Erweiterung (policy-changes counter)
- Rollout-Reihenfolge + Tests + offene Fragen
Bau-Trigger: erster PR der ein Tool mit policyHint:'destructive'
in die Registry bringt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
