Ordering + limit-only Test für created_at DESC in DependencyExtractionFeatureTest.php UI Test für masked Identifier (ID: 123456…) + Guest-Access blocked in InventoryItemDependenciesTest.php Quickstart ergänzt um manuellen <2s Check in quickstart.md pr-gate Checkbox-Format normalisiert (kein leading space) in pr-gate.md Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #49
77 lines
7.7 KiB
Markdown
77 lines
7.7 KiB
Markdown
# PR Gate Checklist: Inventory Dependencies Graph
|
||
|
||
**Purpose**: PR-Review-Checklist zur Bewertung der Anforderungsqualität für Spec 042 (50% Daten/Pipeline, 50% Darstellung). Fokus: messbar, deterministisch reviewbar, scope-stabil durch „Enumerate now“.
|
||
**Created**: 2026-01-07
|
||
**Feature**: `specs/042-inventory-dependencies-graph/spec.md`
|
||
|
||
**Note**: This checklist is generated by the `/speckit.checklist` command based on feature context and requirements.
|
||
|
||
## Requirement Completeness
|
||
|
||
- [x] CHK001 Ist die Relationship-Taxonomie vollständig enumeriert (Set an Typen) und pro Typ mit Definition + Richtung + Beispiel beschrieben? [Completeness, Spec §FR1]
|
||
- [x] CHK002 Sind alle in-scope „foundational Intune objects“ explizit aufgelistet (Enumerate now) inkl. klarer Exclusions, um Scope zu binden? [Gap, Spec §FR2, Plan §Risks]
|
||
- [x] CHK003 Sind Mindestfelder einer Dependency-Edge als Requirement beschrieben (source, target, relationship_type, directionality, provenance/derived_from, timestamps/created_at, optional metadata)? [Gap, Spec §FR2]
|
||
- [x] CHK004 Ist klar spezifiziert, wie „inventory item“ eindeutig referenziert wird (stable identifier), und wie foundation objects referenziert werden (ID/uri/type tuple)? [Gap, Plan §Dependencies]
|
||
- [x] CHK005 Sind inbound UND outbound Abfragen als explizite Requirements beschrieben (inkl. erwarteter Sortierung/Limitierung oder bewusst „unspecified“)? [Completeness, Spec §FR3]
|
||
- [x] CHK006 Sind Missing-Prerequisites als eigene Requirement-Klasse beschrieben (Erkennung, Darstellung, und welche Daten minimal gezeigt werden dürfen)? [Completeness, Spec §FR4, Scenario 2]
|
||
- [x] CHK007 Ist Relationship-Type-Filtering vollständig spezifiziert (Scope, Default, Mehrfachauswahl ja/nein, Verhalten bei „none selected“)? [Completeness, Spec §Scenario 3]
|
||
- [x] CHK008 Sind Tenant-Scoping und Access Control Requirements konkretisiert (welche Rollen/Capabilities; Read vs View Details; ggf. audit expectations)? [Gap, Spec §FR5]
|
||
|
||
## Requirement Clarity
|
||
|
||
- [x] CHK009 Ist „inbound“ vs „outbound“ formal definiert pro Relationship-Type (nicht nur im Textbeispiel), um Interpretationsspielraum zu vermeiden? [Clarity, Spec §Scenario 1, FR3]
|
||
- [x] CHK010 Sind Relationship-Namen und Semantik konsistent (z.B. „assigned to“ ist eindeutig Richtung A→B) und nicht synonym/überlappend? [Clarity, Spec §FR1]
|
||
- [x] CHK011 Ist „blast radius“ in messbare Graph-Konzepte übersetzt (z.B. „outbound edges bis Tiefe N“, „both directions“, oder explizit „only direct neighbors“)? [Ambiguity, Spec §Purpose]
|
||
- [x] CHK012 Ist „prerequisite“ eindeutig definiert (hard vs informational, required vs optional) und ist diese Definition in Missing-Prerequisites konsistent wiederverwendet? [Ambiguity, Spec §Purpose, Scenario 2]
|
||
- [x] CHK013 Ist „safe warning“ (NFR2) klar operationalisiert: Inhalt/Felder, Severity, Persistenz, und wo es sichtbar wird (Run-Log vs UI vs Audit)? [Clarity, Spec §NFR2]
|
||
|
||
## Requirement Consistency
|
||
|
||
- [x] CHK014 Sind Scenario-Beispiele („uses“, „assigned to“, „scoped by“) vollständig Teil der FR1-Taxonomie (keine scenario-only Typen)? [Consistency, Spec §Scenario 1, FR1]
|
||
- [x] CHK015 Ist FR4 („missing prerequisites“) konsistent mit „ohne deleted state in core inventory“ beschrieben (kein implizites soft-delete/archived eingeführt)? [Consistency, Spec §FR4]
|
||
- [x] CHK016 Sind NFR1 (idempotent) und SC2 (deterministic output) konfliktfrei und eindeutig, was Gleichheit bedeutet (Edge-Set, Normalisierung, Sortierung)? [Consistency, Spec §NFR1, SC2]
|
||
- [x] CHK017 Ist der Tenant-Scope konsistent in Storage, Query und UI (keine impliziten cross-tenant Graphs; Out-of-scope ist explizit)? [Consistency, Spec §FR5, Out of Scope]
|
||
|
||
## Acceptance Criteria Quality
|
||
|
||
- [x] CHK018 Ist SC1 („unter 2 Minuten“) so definiert, dass Reviewer objektiv prüfen können, was „determine prerequisites and blast radius“ konkret bedeutet (Tiefe, Umfang, Informationsumfang)? [Measurability, Spec §SC1]
|
||
- [x] CHK019 Ist SC2 so messbar formuliert, dass deterministische Output-Gleichheit ohne Interpretationsspielraum prüfbar ist (z.B. canonical ordering + uniqueness rules)? [Measurability, Spec §SC2]
|
||
- [x] CHK020 Gibt es eine klare Traceability zwischen FR1–FR5 und Success Criteria (jedes FR hat mindestens ein objektives Akzeptanzkriterium oder ist bewusst als „non-testable“ markiert)? [Gap, Spec §Functional Requirements, Success Criteria]
|
||
|
||
## Scenario Coverage
|
||
|
||
- [x] CHK021 Deckt die Spec explizit den Zero-State ab („no edges“ / „no deps“), inkl. erwarteter UI-Messaging-Requirement? [Gap, Spec §User Scenarios & Testing]
|
||
- [x] CHK022 Deckt die Spec explizit Mixed-Targets ab (Inventory→Foundation, Inventory→Inventory) und ob Foundation→Inventory als inbound dargestellt werden soll? [Gap, Spec §FR2, FR3]
|
||
- [x] CHK023 Gibt es definierte Requirements für „only missing prerequisites“ (alle Targets missing) und wie Filter/Display damit umgehen? [Gap, Spec §Scenario 2]
|
||
|
||
## Edge Case Coverage
|
||
|
||
- [x] CHK024 Sind Unknown/Unsupported References (NFR2) vollständig als Requirements abgedeckt: ob Edge erzeugt wird, ob Node „unknown“ erlaubt ist, ob raw reference gespeichert wird? [Coverage, Spec §NFR2]
|
||
- [x] CHK025 Sind Duplicate References innerhalb eines Items geregelt (Dedup-Key, Merge Rules), um NFR1/SC2 deterministisch einzuhalten? [Gap, Spec §NFR1, SC2]
|
||
- [x] CHK026 Sind zyklische Dependencies als Requirement adressiert (Erkennung/Handling/Traversal-Limits), damit „blast radius“ nicht unendlich wird? [Gap, Spec §Purpose, Plan §Risks]
|
||
- [x] CHK027 Sind Grenzen für Edge-Explosion als Requirements spezifiziert (Limits, pagination, depth caps, server-side constraints), nicht nur als Risiko erwähnt? [Gap, Plan §Risks]
|
||
|
||
## Non-Functional Requirements
|
||
|
||
- [x] CHK028 Ist Idempotenz (NFR1) präzisiert: Scope (per-run vs global), Unique Keys, Upsert vs Replace-All, und ob Deletions/Orphan-Edges geregelt sind? [Clarity, Spec §NFR1]
|
||
- [x] CHK029 Ist „must not fail an inventory sync run“ präzisiert: welche Fehler sind soft-fail, welche sind hard-fail, und wie wird das für Reviewer nachvollziehbar? [Clarity, Spec §NFR2]
|
||
- [x] CHK030 Sind Performance-/Skalierungsanforderungen spezifiziert (UI Query Latency, max edges returned, extraction time budget) statt nur „Risiko“? [Gap, Plan §Risks]
|
||
- [x] CHK031 Sind Security/Privacy-Anforderungen spezifiziert, welche foundation-object Daten sichtbar sein dürfen (IDs vs Names) und ob das tenant- & permission-scoped ist? [Gap, Spec §FR5]
|
||
|
||
## Dependencies & Assumptions
|
||
|
||
- [x] CHK032 Sind Abhängigkeiten zu Spec 040 (stable identifiers) und Spec 041 (UI navigation/detail pages) als Requirements eindeutig dokumentiert (hard requirement vs optional)? [Clarity, Plan §Dependencies]
|
||
- [x] CHK033 Sind Annahmen über heterogene Reference-Shapes explizit dokumentiert und ist klar, wie neue Shapes in Scope aufgenommen werden (Change control / taxonomy update)? [Assumption, Plan §Risks]
|
||
- [x] CHK034 Ist explizit dokumentiert, wann Edges extrahiert werden (im sync run vs post-processing), und wie Staleness/Refresh geregelt ist? [Gap, Spec §NFR1]
|
||
|
||
## Ambiguities & Conflicts
|
||
|
||
- [x] CHK035 Sind Begriffe „missing“, „not present“, „excluded“, „out-of-scope“ sauber definiert und konsistent verwendet (kein Vermischen von Datenzustand und Scope)? [Ambiguity, Spec §FR4, Out of Scope]
|
||
- [x] CHK036 Ist klar, ob Filtering nur Relationship-Types betrifft oder auch Node-Types (Inventory vs Foundation) und ob beides kombinierbar sein soll? [Gap, Spec §Scenario 3]
|
||
|
||
## Notes
|
||
|
||
- Check items off as completed: `[x]`
|
||
- Findings als kurze Stichpunkte direkt unter dem jeweiligen Item ergänzen
|
||
- Jede `/speckit.checklist` Ausführung erzeugt eine neue Datei (kein Overwrite)
|