131 lines
8.0 KiB
Markdown
131 lines
8.0 KiB
Markdown
## 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 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
|