browser/openspec/changes/replace-scum-projections-with-real-data-management/specs/scum-squad-management/spec.md

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