## 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