## 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_id` or snapshot fields that are internal IDs or internal foreign keys #### Scenario: Select a historical candidate - **WHEN** a user selects a candidate with `historical=true` and 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 as the authoritative sources for continuing from audit, risk, finance and link nodes. It SHALL expose only actions whose complete required reference is present and reliable. #### Scenario: Continue from a complete reference - **WHEN** a node 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: 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