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

2.1 KiB

Raw Blame History

Feature Specification: Inventory Dependencies Graph

Feature Branch: feat/042-inventory-dependencies-graph
Created: 2026-01-07
Status: Draft

Purpose

Represent and surface dependency relationships between inventory items and foundational Intune objects so admins can understand blast radius and prerequisites.

User Scenarios & Testing

Scenario 1: View dependencies for an item

Given an inventory item
When the user opens its dependencies view
Then they can see inbound and outbound relationships (e.g., “uses”, “assigned to”, “scoped by”)

Scenario 2: Identify missing prerequisites

Given an item references a prerequisite object not present in inventory
When the user views dependencies
Then missing prerequisites are clearly indicated

Scenario 3: Filter dependencies by relationship type

Given multiple relationship types exist
When the user filters by relationship type
Then only matching edges are shown

Functional Requirements

FR1: Define a normalized set of relationship types.
FR2: Store dependency edges between inventory items and other objects (including non-inventory foundations when applicable).
FR3: Allow querying inbound/outbound edges for a given item.
FR4: Show missing prerequisites without requiring a separate “deleted” state in core inventory.
FR5: All dependency data is tenant-scoped and access-controlled.

Non-Functional Requirements

NFR1: Dependency extraction must be idempotent (re-runnable without duplicating edges).
NFR2: Dependency extraction must not fail an inventory sync run if an unknown/unsupported reference is encountered; it should record a safe warning.

Success Criteria

SC1: Admins can determine prerequisites and blast radius for an item in under 2 minutes.
SC2: For supported relationship types, dependency edges are consistent across re-runs (deterministic output).

Out of Scope

Automatic remediation.
Cross-tenant dependency graphs.

Program: specs/039-inventory-program/spec.md
Core: specs/040-inventory-core/spec.md

2.1 KiB Raw Blame History