ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
dev
TenantAtlas/specs/042-inventory-dependencies-graph/research.md
ahmido 361e301f67 feat/042-inventory-dependencies-graph (#49) 
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
2026-01-10 00:20:14 +00:00

2.5 KiB
Raw Permalink Blame History

Research — Inventory Dependencies Graph (042)

This document resolves all implementation clarifications for the MVP and records the key decisions with rationale and alternatives.

Decisions

1) Pagination vs limit-only

  • Decision: Limit-only (no pagination/cursors in MVP).
  • Rationale: Pagination introduces cursor semantics, UI states, sorting guarantees, and additional tests; MVP goal is fast/stable/testable.
  • Alternatives considered:
    • Add pagination now: rejected due to complexity and low MVP value.

2) Edge limits in UI

  • Decision: 50 per direction (inbound and outbound), so up to 100 total when showing both directions.
  • Rationale: Keeps each query bounded and predictable; matches existing UI composition (combine inbound + outbound).
  • Alternatives considered:
    • 50 total across both directions: rejected because it makes results direction-dependent and less intuitive.

3) Relationship-type filter (UI)

  • Decision: Add single-select Relationship filter with default All; persists in querystring.
  • Rationale: Small UX improvement with high usefulness; minimal risk.
  • Alternatives considered:
    • No relationship filter: rejected (spec requires it; improves scanability).

4) Unknown/unsupported reference shapes

  • Decision: Warning-only (no edge created).
  • Rationale: Creating “missing” edges for unknown shapes is misleading; it inflates perceived missing prerequisites and reduces trust.
  • Alternatives considered:
    • Create missing edge: rejected as potentially inaccurate.

5) Where warnings are stored

  • Decision: Persist warnings on the sync run record at InventorySyncRun.error_context.warnings[].
  • Rationale: Auditable, debuggable, no new schema, consistent with “observable automation”.
  • Alternatives considered:
    • Per-item warnings in InventoryItem.meta_jsonb: rejected (pollutes inventory, harder to reason about run-level issues).
    • New warnings table: rejected (migrations/models/retention/cleanup burden).

6) Foundation object typing

  • Decision: For target_type='foundation_object', always store metadata.foundation_type.
  • Rationale: Deterministic UI labeling/resolution; avoids inference.
  • Alternatives considered:
    • Infer foundation type from relationship type: rejected (brittle).

Notes / Implementation Implications

  • If the current code path creates missing edges for unknown assignment shapes, it must be adjusted to warning-only to match spec.
  • Warning payload shape should be stable: {type: 'unsupported_reference', policy_id, raw_ref, reason}.