ahmido 9c56a2349a feat/047-inventory-foundations-nodes (#51 )

Adds Inventory Sync toggle include_foundations (default true) + persistence tests
Adds Coverage “Dependencies” column (✅/—) derived deterministically from graph_contracts (no Graph calls)
Spec/tasks/checklists updated + tasks ticked off

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

2026-01-10 20:47:29 +00:00

1.4 KiB

Raw Blame History

Phase 1 Data Model: Foundations in Inventory (047)

Existing Entities

`InventoryItem`

Represents the last observed state for a tenant-scoped Intune object.

Key fields (existing schema)

tenant_id (FK)
policy_type (string)
external_id (string)
display_name (nullable string)
category (nullable string)
platform (nullable string)
meta_jsonb (jsonb, safe/whitelisted)
last_seen_at (timestamp)
last_seen_run_id (FK to InventorySyncRun)

New Semantics (no schema change)

Foundation Nodes

A foundation node is an InventoryItem where:

policy_type is one of config('tenantpilot.foundation_types')[*].type
category is set from the foundation type config (MVP expects Foundations)

In-scope foundation types (MVP)

roleScopeTag (Scope Tag)
assignmentFilter (Assignment Filter)
notificationMessageTemplate (Notification Message Template)

Relationships

Tenant isolation: all foundation nodes are strictly tenant-scoped.
Dependencies (Spec 042) can reference foundations via edges, and Spec 042.2 can resolve their display names locally by matching (tenant_id, policy_type, external_id).

Validation / Invariants

Idempotency: repeated sync runs update last_seen_at and last_seen_run_id deterministically without creating duplicates.
Data minimization: foundation sync must not store non-whitelisted payload data in meta_jsonb.

1.4 KiB Raw Blame History