8.0 KiB
ADDED Requirements
Requirement: Shared Cross-View Investigation Surface
The frontend SHALL open actor, resource, request, correlation, finance, Integration, agent-activity and enterprise-activity investigations through reusable modal or drawer components. It SHALL NOT require a standalone timeline route for these cross-view investigations.
Scenario: Open an investigation from a business row
- WHEN an authorized user selects an audit or activity action from a supported business row
- THEN the frontend MUST construct a typed investigation target from the row's documented stable fields
- AND it MUST open the shared investigation surface without navigating to a standalone timeline page
Scenario: Replace an open investigation target
- WHEN the user opens a second investigation after another target was loaded
- THEN the shared surface MUST clear stale content before loading the new target
- AND a late response from the previous target MUST NOT replace the current result
Requirement: Deterministic Investigation Target Resolution
The frontend SHALL resolve investigation targets in this order: a platform internal stable ID for a platform resource timeline, a documented subject-safe business identifier for agent or enterprise activity, an explicit API investigation reference, an exact Registry resource-key search when no internal resource ID exists, or no entry. It SHALL NOT infer a target from display text or proximity.
Scenario: A platform resource ID is available
- WHEN a platform business response contains the documented non-zero internal resource ID
- THEN the frontend MUST call the resource timeline with the mapped resource type and that ID
- AND it MUST NOT search by the display name or business Key to replace the available ID
Scenario: Only a supported Registry Key is available
- WHEN a platform investigation reference contains a supported resource type and business Key but no resource ID
- THEN the frontend MUST use the exact resource search endpoint
- AND zero or multiple matches MUST remain unresolved until the user makes an explicit choice
Scenario: No stable target exists
- WHEN the required internal ID, subject identifier or explicit investigation reference is missing
- THEN the frontend MUST hide or disable the entry
- AND it MUST NOT infer a relationship from a name, summary, timestamp, identifier prefix, adjacent record or current-account profile
Requirement: Exact Registered Resource Selection
The frontend SHALL support exact Registry lookup only for iot_card, device, shop, order and refund. It SHALL pass the selected candidate's returned resource_type/resource_id unchanged to the resource timeline while keeping internal identifiers out of the presentation.
Scenario: Present an exact resource candidate
- WHEN exact lookup returns a candidate with
identity_snapshot - THEN the frontend MUST display only a resource-type-specific whitelist of business-readable fields
- AND it MUST NOT display
resource_idor snapshot fields that are internal IDs or internal foreign keys
Scenario: Select a historical candidate
- WHEN a user selects a candidate with
historical=trueand a stable returned resource ID - THEN the frontend MUST use the returned type and ID without modification
- AND it MUST NOT claim that the resource still exists in the current business table
Requirement: Role-Isolated Resource Activity Navigation
The frontend SHALL choose platform, agent or enterprise resource investigation APIs solely from the authenticated subject and the documented source-page fields. Agent and enterprise navigation SHALL NOT fall back to platform audit or Registry search.
Scenario: Open agent activity
- WHEN an agent opens a supported card, device, allocation, exchange, shop or enterprise activity
- THEN the frontend MUST use the documented ICCID, VirtualNo or business number with the agent activity endpoint
- AND it MUST NOT send agent identity or shop scope as proof of authorization
Scenario: Open enterprise activity
- WHEN an enterprise user opens activity for a currently authorized card or device
- THEN the frontend MUST use ICCID or VirtualNo with the enterprise activity endpoint
- AND it MUST NOT use the enterprise route parameter or a platform internal ID as authorization evidence
Scenario: Subject activity becomes unavailable
- WHEN authorization is revoked, the resource is out of scope, or the subject endpoint rejects access
- THEN the frontend MUST present an activity-unavailable state
- AND it MUST NOT retry through a platform endpoint, Registry search or legacy operation log
Requirement: Business and Finance Entry Matrix
The frontend SHALL implement the documented row-level navigation matrix for asset, organization, account, order, refund, recharge, wallet and fund-summary contexts. Each action SHALL be independently visible only when its complete stable parameter set and required permission are available.
Scenario: Open resource and finance investigations independently
- WHEN a business record contains both a resource ID and a stable finance condition
- THEN the frontend MUST offer the applicable resource audit and finance investigation actions independently
- AND failure or absence of one parameter set MUST NOT suppress the other valid action
Scenario: Let the server resolve finance relationships
- WHEN the frontend opens finance history from an order, refund, recharge, wallet or shop
- THEN it MUST submit only the stable condition explicitly returned by the source business API
- AND it MUST NOT derive or supplement payment, refund, wallet, approval or third-party identifiers from text or number prefixes
Requirement: Investigation Reference Continuation
The frontend SHALL treat investigation_refs and documented Integration references on supported source details as the authoritative sources for continuing an investigation. It SHALL expose only actions whose complete required reference is present and reliable. Shared investigation drawers SHALL remain read-only and SHALL NOT repeat nested investigation action groups inside their result nodes.
Scenario: Continue from a complete reference
- WHEN a supported source detail contains a complete actor, resource, request, correlation or Integration reference
- THEN the frontend MUST pass its type and identifier unchanged to the matching shared investigation surface
Scenario: Display a result inside the shared drawer
- WHEN a shared investigation drawer renders an event, resource, link, finance or Integration result
- THEN it MUST present that result as read-only evidence without nested investigation action buttons
- AND it MUST preserve documented source and reference-only boundaries in the displayed facts
Scenario: Suppress unavailable or self-referential navigation
- WHEN a reference is incomplete, its fidelity is false, or its event target is the detail already being displayed
- THEN the frontend MUST hide the corresponding action
- AND it MUST NOT create a substitute identifier or reopen the same detail
Requirement: Read-Only Presentation and Scroll Isolation
All shared investigation surfaces SHALL remain read-only, hide non-business internal identifiers by default, and isolate modal scrolling from the underlying page.
Scenario: Display an investigation surface
- WHEN a modal or drawer is open
- THEN it MUST use a modal overlay, append to the document body, and lock underlying-page scrolling
- AND it MUST remain usable within its own scroll container at supported viewport sizes
Scenario: Inspect a read-only result
- WHEN audit, activity, finance, link or Integration data is displayed
- THEN the UI MUST NOT expose mutation, recovery, retry, deletion, disposition, blocking or export actions
- AND raw internal IDs MUST be retained only as navigation parameters unless an explicitly authorized developer-investigation workflow requires display