feat: 审计链路

openspec/changes/align-audit-cross-view-navigation/specs/audit-cross-view-navigation/spec.md

@@ -0,0 +1,124 @@
+## 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