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
2.5 KiB
2.5 KiB
Feature Specification: Inventory Program (Meta)
Feature Branch: feat/039-inventory-program
Created: 2026-01-07
Status: Draft
Purpose
This is an epic/program-level specification that anchors vision, scope, principles, and a roadmap for an Inventory-first approach across TenantPilot.
This document is intentionally non-implementation and does not require immediate code changes.
Program Goals
- Establish Inventory as the primary substrate for analysis, reporting, monitoring, and UI navigation (Inventory is “last observed”, not absolute Intune truth).
- Maintain immutable snapshots/backups as explicit actions (manual/scheduled), separate from inventory sync.
- Provide a config-driven coverage/support matrix across policy types (backup/restore/risk/support).
- Build toward dependency visibility, cross-tenant comparison/promotion, and drift detection.
Key Definitions
- Inventory: TenantPilot’s last observed catalog of Intune objects (mutable; updated by sync runs).
- Snapshot/Backup: Immutable capture of an object’s payload for versioning/restore (explicit action).
- Coverage/Support Matrix: Derived view describing support level (backup/restore/risk) per policy type.
Data Domains
- Inventory Items
- Sync Runs (observability)
- Support/Capabilities derived from contracts/config
- Dependencies (links between inventory items and foundation objects)
- Cross-tenant context (explicit and access-checked)
Principles (Program-level)
- Inventory-first, snapshots-second
- Read/write separation by default (preview + confirmation + audit + tests for writes)
- Single contract path to Graph
- Deterministic capabilities
- Tenant isolation is non-negotiable
- Automation is idempotent & observable (locks, run records, stable error codes)
- Data minimization & safe logging
Roadmap / Decomposition
- Spec 040 — Inventory Core: inventory items + sync runs + deterministic selection + missing semantics
- Spec 041 — Inventory UI: inventory lists, coverage matrix, sync runs UI, policy viewer
- Spec 042 — Dependencies Graph: inventory_links and dependency views (assignments/scope tags/filters first)
- Spec 043 — Cross-tenant Compare & Promotion: read-only compare first; gated promotion later
- Spec 044 — Drift MVP: drift findings based on inventory/run metadata and optional hashes
Non-Goals
- This meta spec does not define concrete schemas or endpoints.
- This meta spec does not introduce new write paths (promotion/remediation) without dedicated feature specs.