# 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.