ahmido
a449ecec5b
Beschreibung Implementiert das Drift MVP Feature (Spec: 044-drift-mvp) mit Fokus auf automatische Drift-Erkennung zwischen Inventory Sync Runs und Bulk-Triage für Findings. Was wurde implementiert? Drift-Erkennung: Vergleicht Policy-Snapshots, Assignments und Scope Tags zwischen Baseline- und Current-Runs. Deterministische Fingerprints verhindern Duplikate. Findings UI: Neue Filament Resource für Findings mit Listen- und Detail-Ansicht. DB-only Diffs (keine Graph-Calls zur Laufzeit). Bulk Acknowledge: "Acknowledge selected" (Bulk-Action auf der Liste) "Acknowledge all matching" (Header-Action, respektiert aktuelle Filter; Type-to-Confirm bei >100 Findings) Scope Tag Fix: Behebt False Positives bei Legacy-Daten ohne scope_tags.ids (inferiert Default-Werte). Authorization: Tenant-isoliert, Rollen-basiert (Owner/Manager/Operator können acknowledge). Tests: Vollständige Pest-Coverage (28 Tests, 347 Assertions) für Drift-Logik, UI und Bulk-Actions. Warum diese Änderungen? Problem: Keine automatisierte Drift-Erkennung; manuelle Triage bei vielen Findings ist mühsam. Lösung: Async Drift-Generierung mit persistenter Findings-Tabelle. Safe Bulk-Tools für Massen-Triage ohne Deletes. Konformität: Folgt AGENTS.md Workflow, Spec-Kit (Tasks + Checklists abgehakt), Laravel/Filament Best Practices. Technische Details Neue Dateien: ~40 (Models, Services, Tests, Views, Migrations) Änderungen: Filament Resources, Jobs, Policies DB: Neue findings Tabelle (JSONB für Evidence, Indexes für Performance) Tests: ./vendor/bin/sail artisan test tests/Feature/Drift --parallel → 28 passed Migration: ./vendor/bin/sail artisan migrate (neue Tabelle + Indexes) Screenshots / Links Spec: spec.md Tasks: tasks.md (alle abgehakt) UI: Findings-Liste mit Bulk-Actions; Detail-View mit Diffs Checklist Tests passieren (parallel + serial) Code formatiert (./vendor/bin/pint --dirty) Migration reversibel Tenant-Isolation enforced No Graph-Calls in Views Authorization checks Spec + Tasks aligned Deployment Notes Neue Migration: create_findings_table Neue Permissions: drift.view, drift.acknowledge Queue-Job: GenerateDriftFindingsJob (async, deduped)
82 lines
3.5 KiB
Markdown
82 lines
3.5 KiB
Markdown
# Feature Specification: Drift MVP (044)
|
|
|
|
## Purpose
|
|
|
|
Help admins quickly spot and triage configuration “drift”: what changed between two inventory snapshots.
|
|
|
|
This MVP is about visibility and acknowledgement (triage), not automatic fixes.
|
|
|
|
## User Scenarios
|
|
|
|
### Scenario 1: View drift summary
|
|
|
|
- Given the system has at least two successful inventory snapshots for the same selection/scope
|
|
- When an admin opens Drift
|
|
- Then they see a summary of what was added, removed, or changed since the previous snapshot
|
|
|
|
### Scenario 2: Drill into a drift finding
|
|
|
|
- Given drift findings exist for a comparison
|
|
- When an admin opens a specific finding
|
|
- Then they can see what changed and which two snapshots were compared
|
|
|
|
### Scenario 3: Acknowledge / triage
|
|
|
|
- Given a drift finding exists
|
|
- When an admin acknowledges it
|
|
- Then it no longer appears in “new” views, but remains available for audit/history
|
|
|
|
## Rules
|
|
|
|
### Coverage (MVP)
|
|
|
|
- Drift findings cover **policies, their assignments, and scope tags** for the selected scope.
|
|
|
|
### Baseline and comparison selection
|
|
|
|
- Drift always compares two successful inventory snapshots for the same selection/scope.
|
|
- The “current” snapshot is the latest successful snapshot for that scope.
|
|
- The “baseline” snapshot is the previous successful snapshot for that scope.
|
|
|
|
### Change types
|
|
|
|
Each drift finding must be categorized as one of:
|
|
|
|
- **added**: the item exists in current but not in baseline
|
|
- **removed**: the item exists in baseline but not in current
|
|
- **modified**: the item exists in both but differs (including assignment target and/or intent changes)
|
|
|
|
### Acknowledgement
|
|
|
|
- Acknowledgement is **per comparison** (baseline + current within a scope).
|
|
- Acknowledgement does **not** carry forward to later comparisons.
|
|
|
|
### UI states
|
|
|
|
- **blocked**: If fewer than two successful snapshots exist for the same scope, Drift shows a clear blocked state and does not attempt generation.
|
|
- **error**: If drift generation fails for a comparison, Drift shows a clear error state with safe information and reference identifiers to the recorded run.
|
|
|
|
### Default views
|
|
|
|
- Default Drift summary and default finding lists show **new** findings only.
|
|
- Acknowledged findings are accessible via an explicit filter.
|
|
|
|
### Run tracking (status, errors, idempotency)
|
|
|
|
- Drift generation status and errors must be recorded in a **persisted run record** so that progress/failure survives refresh and can be inspected later.
|
|
- Re-opening Drift for the same comparison must be idempotent (it should not create duplicate work for the same comparison).
|
|
|
|
### Determinism and stable identity
|
|
|
|
- For the same scope + baseline + current, Drift must produce the same set of findings.
|
|
- Each finding must have a stable identifier (“fingerprint”) so triage actions can reliably reference the same drift item within a comparison.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- With two successful snapshots for the same scope, Drift shows a summary of **added/removed/modified** items for that comparison.
|
|
- With fewer than two successful snapshots for the same scope, Drift shows **blocked** and does not start generation.
|
|
- If generation fails, Drift shows **error** and provides reference identifiers to the persisted run record.
|
|
- Default views exclude acknowledged findings, and acknowledged findings remain available via filter.
|
|
- Acknowledging a finding records who/when acknowledged and hides it from “new” views.
|
|
- Re-running generation for the same comparison does not create duplicate work and produces consistent results.
|