ahmido dedca3c612 spec: add inventory specs 039-044 (#42 )

What’s included
	•	specs/039-inventory-program/ — program/epic overview (vision + phased plan)
	•	specs/041-inventory-ui/ — UI skeleton (Inventory list, Coverage, Sync Runs)
	•	specs/042-inventory-dependencies-graph/ — dependency graph skeleton (assignments/filters/scope tags → later)
	•	specs/043-cross-tenant-compare-and-promotion/ — compare/promotion skeleton (read-only first; writes gated later)
	•	specs/044-drift-mvp/ — drift detection skeleton (read-only by default)

Why

We need a clear, spec-first structure for:
	•	separating Inventory (“last observed”) from Snapshots/Backups (immutable)
	•	scaling to MSP / multi-tenant workflows (portfolio, compare, monitoring)
	•	making future modules (security suite, drift, promotion) consistent with the Constitution (fail-safe, auditability, contract-driven Graph)

Scope / Non-goals (this PR)
	•	No implementation tasks executed
	•	No DB migrations, services, jobs, or UI changes
	•	No changes to Graph contracts or supported policy types

Review focus
	•	Naming/numbering and folder structure (spec.md, plan.md, tasks.md for each spec)
	•	Scope boundaries and non-goals across 041–044
	•	Alignment with Constitution principles (tenant isolation, read-only default for analysis, explicit gating for high-risk writes)

Follow-up (next PRs)
	•	Spec 040: Inventory Core (data model + selection hash + missing semantics + NFRs + tests)
	•	Implementation PRs will be split per spec (040 → 041 → 042/043/044)

⸻

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #42

2026-01-07 14:01:07 +00:00

1.7 KiB

Raw Permalink Blame History

Feature Specification: Drift MVP

Feature Branch: feat/044-drift-mvp
Created: 2026-01-07
Status: Draft

Purpose

Detect and report drift between expected and observed states using inventory and run metadata.

This MVP focuses on reporting and triage, not automatic remediation.

User Scenarios & Testing

Scenario 1: View drift summary

Given inventory sync has run at least twice
When the admin opens Drift
Then they see a summary of changes since the last baseline

Scenario 2: Drill into a drift finding

Given a drift finding exists
When the admin opens the finding
Then they see what changed, when, and which run observed it

Scenario 3: Acknowledge/triage

Given a drift finding exists
When the admin marks it acknowledged
Then it is hidden from “new” lists but remains auditable

Functional Requirements

FR1: Define a baseline concept (e.g., last completed run for a selection scope).
FR2: Produce drift findings for adds/removals/metadata changes based on inventory/run state.
FR3: Provide drift UI with summary and details.
FR4: Allow acknowledgement/triage states.

Non-Functional Requirements

NFR1: Drift generation must be deterministic for the same baseline and scope.
NFR2: Drift must remain tenant-scoped and safe to display.

Success Criteria

SC1: Admins can identify drift across supported types in under 3 minutes.
SC2: Drift results are consistent across repeated generation for the same baseline.

Out of Scope

Automatic revert/promotion.

Program: specs/039-inventory-program/spec.md
Core: specs/040-inventory-core/spec.md
Compare: specs/043-cross-tenant-compare-and-promotion/spec.md

1.7 KiB Raw Permalink Blame History