da18d3cb14
feat/042-inventory-dependencies-graph ( #50 )
...
Dieses PR liefert den Inventory Dependencies Graph end-to-end: Abhängigkeiten (Edges) werden aus Inventory-Sync-Daten extrahiert, tenant-sicher gespeichert und in der Inventory Item Detailansicht angezeigt.
Ziel: Admins können Prerequisites + Blast Radius (direct) schnell erkennen, ohne Snapshot/Restore anzufassen.
⸻
Was ist drin?
Dependency Graph (Edges)
• inventory_links Schema + Indizes + idempotentes Upsert (Unique Key)
• Relationship Types (u.a.):
• assigned_to_include, assigned_to_exclude
• uses_assignment_filter
• scoped_by_scope_tag
• UI: Inventory Item → Dependencies Section
• Direction Filter: All / Inbound / Outbound
• Relationship Filter: All + spezifische Relationship Types
• Missing-Badge + sicheres Tooltip (safe subset)
Safety / Observability
• Unknown/unsupported Shapes erzeugen keine Edges, sondern:
• Warning in InventorySyncRun.error_context.warnings[]
• optional info-log (ohne Secrets)
• Limit-only Semantik (MVP): bis zu 50 Edges pro Richtung (max 100 bei “All”)
• Blast Radius in MVP = direct only (kein depth>1 traversal)
Name Resolution (lokal, ohne Entra Calls)
• Resolver/DTO Layer für deterministische Labels (kein “Unknown” mehr)
• Auflösung aus lokaler DB nur für Foundations, wenn vorhanden:
• scope_tag → roleScopeTag
• assignment_filter → assignmentFilter
• aad_group bleibt bewusst external ref: “Group (external): …” (keine Graph/Entra Lookups im UI)
• Zentraler FoundationTypeMap als Source-of-Truth (keine Hardcodings)
⸻
Out of Scope / Follow-up
• Entra Group Name Resolution (braucht eigenes “Group Inventory” Modul + Permissions)
• Foundations als Inventory Items / Coverage Tab (Scope Tags / Assignment Filters sichtbar & syncbar)
→ folgt als separater PR (Inventory Core/UI), damit 042 sauber “Edges-only” bleibt.
⸻
Tests / Verifikation
• Targeted Pest Tests (Unit + Feature + UI smoke) für:
• deterministische Edge-Erzeugung + idempotent upsert
• tenant isolation (UI/Query)
• warnings auf Run Record
• resolver/name rendering + links (wo möglich)
• pint --dirty ausgeführt
⸻
Manual QA (UI)
1. Inventory Sync Run mit include_dependencies=true starten
2. Inventory Item öffnen → Dependencies prüfen:
• include/exclude + filter + scoped_by sichtbar (wenn vorhanden)
• Relationship/Direction Filter funktionieren
• keine “Unknown” Labels mehr, sondern deterministische Labels
Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #50
2026-01-10 12:50:08 +00:00
dedca3c612
spec: add inventory specs 039-044 ( #42 )
...
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
2026-01-07 14:01:07 +00:00
