ahmido
361e301f67
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
48 lines
2.5 KiB
Markdown
48 lines
2.5 KiB
Markdown
# 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}`.
|