TenantAtlas/specs/047-inventory-foundations-nodes/research.md
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

37 lines
2.2 KiB
Markdown

# Phase 0 Research: Foundations in Inventory (047)
## Context
This feature makes specific Intune “foundation” objects first-class `InventoryItem` records so the Dependencies UI (Spec 042.2) can resolve names from the local DB (no UI-time Graph calls).
Foundation types in scope are already configured in `config('tenantpilot.foundation_types')`:
- `roleScopeTag`
- `assignmentFilter`
- `notificationMessageTemplate`
Graph contract registry entries exist for all three types in `config/graph_contracts.php` under `types.*.resource`.
## Decisions
### Decision: Reuse existing Inventory sync flow (`InventorySyncService`) to sync foundation types
- **Rationale**: Keeps inventory the “last observed” source of truth, preserves existing locking/idempotency/run observability, and avoids duplicating Graph pagination/retry behavior.
- **Alternatives considered**:
- Separate “Foundations sync” job/service: rejected because it would duplicate run bookkeeping and selection hashing semantics.
- UI-time resolution via Graph: rejected (explicitly out of scope; violates Spec 042.2 / FR-006).
### Decision: Treat foundation types as regular `policy_type` values with a stable `category=Foundations`
- **Rationale**: No schema change; Inventory UI and filters already understand `category` and `policy_type`.
- **Alternatives considered**:
- New table for foundations: rejected (adds joins and complexity; not needed for MVP).
### Decision: Coverage UI presents two matrices (Policies + Foundations)
- **Rationale**: Makes support surface explicit and avoids mixing foundational types into policy-type rows.
- **Alternatives considered**:
- Single combined coverage table with category filter: rejected for MVP clarity.
## Clarifications Resolved
- **Selection semantics**: `include_foundations=true` means “always sync all configured foundation types in addition to selected policy types”. `include_foundations=false` means “never sync foundation types (even if explicitly present in `policy_types`)”.
- **Graph contracts**: Foundation types must be represented in `config/graph_contracts.php` so they are handled via the single contract path.
- **Data minimization**: Only safe, whitelisted `meta_jsonb` is stored (no raw payload dump).