ahmido
dedca3c612
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
55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
# 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.
|
|
|
|
## Related Specs
|
|
|
|
- Program: `specs/039-inventory-program/spec.md`
|
|
- Core: `specs/040-inventory-core/spec.md`
|