54 lines
3.8 KiB
Markdown
54 lines
3.8 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Independently gated squad, member, flag, and territory facts
|
|
The system SHALL store and present squads, squad members, leader/rank meaning, flags, territories, and their relationships only from current-service rows validated by the matching per-resource plugin adapter capability.
|
|
|
|
#### Scenario: Squad and member adapters are compatible
|
|
- **WHEN** squad and member queries complete successfully with verified identifiers, ranks, and player/profile relationships
|
|
- **THEN** Platform transactionally stores server-scoped squads and members and exposes only the leader/rank meaning declared by that adapter
|
|
|
|
#### Scenario: One squad resource is incompatible
|
|
- **WHEN** squad/member queries are compatible but flag ownership or territory coordinates are not
|
|
- **THEN** Platform keeps the verified squad/member capability available, disables only the incompatible resource, and SHALL NOT treat its absence as a verified empty list
|
|
|
|
#### Scenario: Leader meaning is unverified
|
|
- **WHEN** the current schema contains a rank value but the adapter cannot prove which value represents leader
|
|
- **THEN** Platform keeps leader unknown and SHALL NOT assume that a reference-project constant such as rank `4` is authoritative
|
|
|
|
#### Scenario: Flag ownership join is ambiguous
|
|
- **WHEN** a flag/base/profile relationship yields multiple possible squad owners or no verified squad link
|
|
- **THEN** Platform records no squad owner for that flag and exposes no inferred confidence label as fact
|
|
|
|
### Requirement: Searchable and paginated squad roster
|
|
The system SHALL provide a server-authorized local squad-list API and full-width table with bounded name/identifier search, server-side pagination, allowlisted sorting, and deterministic results.
|
|
|
|
#### Scenario: Operator searches squads
|
|
- **WHEN** an authorized operator searches or pages the target server's squads
|
|
- **THEN** Platform returns only matching server-local rows with total/page information, and the table shows squad ID, name, verified leader, member count, flag/territory status, known coordinate, and collection time
|
|
|
|
#### Scenario: No completed squad generation exists
|
|
- **WHEN** squads have not synchronized successfully or the squad adapter is incompatible
|
|
- **THEN** the page shows the corresponding not-yet-available/error state and SHALL NOT render reference, sample, projection, or generated squads
|
|
|
|
### Requirement: Semantic squad detail
|
|
The squad surface SHALL provide a drawer, dialog, or detail route that separates leader, members/ranks, flags, and territory instead of merging unrelated rows into one list.
|
|
|
|
#### Scenario: Operator opens a squad
|
|
- **WHEN** a server-authorized operator selects a squad
|
|
- **THEN** the detail shows only verified leader/member/rank and flag/territory facts with collection times and nullable unknown fields
|
|
|
|
#### Scenario: Verified territory coordinate is selected
|
|
- **WHEN** a squad or flag has a compatible verified coordinate and the realtime-map capability is available
|
|
- **THEN** the detail may navigate to that coordinate on the map without dispatching a new Run query or inventing a fallback point
|
|
|
|
### Requirement: Server-isolated squad APIs
|
|
Squad APIs SHALL authorize the target server and return only bounded local squad, member, flag, and territory fields needed by the management surface.
|
|
|
|
#### Scenario: Foreign selector is supplied
|
|
- **WHEN** a squad, player/member, flag, or territory selector belongs only to another server
|
|
- **THEN** Platform returns no foreign record and does not reveal its existence or server identity
|
|
|
|
#### Scenario: Browser requests protected source material
|
|
- **WHEN** a browser attempts to request raw SCUM.db rows, query text, host paths, database identifiers, or Run connection details
|
|
- **THEN** the API rejects the request and returns only named safe resource fields
|