125 lines
7.5 KiB
Markdown
125 lines
7.5 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 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
|