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
72 lines
2.6 KiB
Markdown
72 lines
2.6 KiB
Markdown
# Feature Specification: Inventory UI
|
||
|
||
**Feature Branch**: `feat/041-inventory-ui`
|
||
**Created**: 2026-01-07
|
||
**Status**: Draft
|
||
|
||
## Purpose
|
||
|
||
Provide a consistent admin UI for browsing Inventory, understanding sync status, and seeing capability/coverage information per policy type.
|
||
|
||
## Users
|
||
|
||
- Tenant Admin (primary)
|
||
- MSP Operator (if cross-tenant access exists; read-only unless explicitly allowed)
|
||
|
||
## User Scenarios & Testing
|
||
|
||
### Scenario 1: Browse inventory
|
||
- Given a tenant context
|
||
- When the user opens Inventory
|
||
- Then they can browse inventory items by type and see core fields (name, platform/type, last observed, status)
|
||
|
||
### Scenario 2: Inspect a single inventory item
|
||
- Given an inventory item exists
|
||
- When the user opens the item details
|
||
- Then they can see normalized metadata and the latest observed payload (or a safe subset if full payload is not available)
|
||
|
||
### Scenario 3: See sync run outcomes
|
||
- Given sync runs exist
|
||
- When the user opens Sync Runs
|
||
- Then they can see run status, timing, counts, and error summaries
|
||
|
||
### Scenario 4: Understand coverage/capabilities
|
||
- Given the system has a support matrix
|
||
- When the user views the coverage table
|
||
- Then they can see which types are supported for backup/restore/preview and any restrictions
|
||
|
||
## Functional Requirements
|
||
|
||
- FR1: Provide an Inventory landing view scoped to the current tenant.
|
||
- FR2: Provide inventory list views grouped by policy type (or category) with pagination/search.
|
||
- FR3: Provide an inventory item detail view showing:
|
||
- stable identifiers
|
||
- last observed timestamps
|
||
- source run reference
|
||
- capability/support status for the item’s type
|
||
- FR4: Provide a Sync Runs list/detail view.
|
||
- FR5: Provide a Coverage/Capabilities view derived from configuration/contract registry.
|
||
- FR6: Enforce tenant isolation in all navigation and data access.
|
||
|
||
## Non-Functional Requirements
|
||
|
||
- NFR1: Pages should remain usable for tenants with large inventories (no full-table loads).
|
||
- NFR2: UI must not expose secrets or unsafe payload fields.
|
||
- NFR3: Errors should be actionable (clear messages + stable error codes where available).
|
||
|
||
## Success Criteria
|
||
|
||
- SC1: Admins can find an inventory item and view its details in under 60 seconds.
|
||
- SC2: Admins can identify the latest completed sync run for a tenant in under 30 seconds.
|
||
- SC3: Coverage view communicates support level clearly enough that admins make the correct decision without trial-and-error.
|
||
|
||
## Out of Scope
|
||
|
||
- Writing changes back to Intune from inventory screens (restore/promotion).
|
||
- Cross-tenant comparison (covered in Spec 043).
|
||
|
||
## Related Specs
|
||
|
||
- Program: `specs/039-inventory-program/spec.md`
|
||
- Core: `specs/040-inventory-core/spec.md`
|