# TASK-157 - Current match player team colors

Status: pending

## Goal

Render current-match player/stat rows with team-aware colors/styles consistent with the historical match detail page.

## Background

The current-match page now has a live player/statistics section backed by:

- `GET /api/current-match/players?server=...`

The current implementation is AdminLog-derived and partial/event-derived because:

- RCON `getSession` player counts are unverified.
- No current RCON player-list wrapper exists in the codebase.
- AdminLog kill events can identify players involved in recent/current events.

The user now wants players to be shown like in the historical detailed match page:

- Players should be visually distinguishable depending on team.
- Team coloring should match or be consistent with the historical match detail page.
- The current live stats section should not remain visually generic.

## Files to Read First

- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `frontend/assets/js/partida-actual.js`
- `frontend/partida-actual.html`
- the historical match detail frontend code and CSS that already color player teams

Inspect the current `/api/current-match/players` payload, the live player rendering, and existing historical detail team classes before choosing frontend or backend changes.

## Expected Files to Modify

Allowed changes:

- `frontend/assets/js/partida-actual.js`
- `frontend/partida-actual.html` if needed
- `frontend/assets/css/historico.css` or relevant current-match CSS
- `backend/app/payloads.py` only if team fields are not currently projected clearly
- `backend/app/rcon_admin_log_storage.py` only if normalized team values need cleanup
- focused tests if backend normalization changes

## Constraints - DO NOT BREAK

- Do not fabricate team values.
- Do not imply the player list is a complete live roster if it is only AdminLog-derived.
- Do not expose raw AdminLog lines.
- Do not expose admin-only/sensitive fields.
- Do not break historical match detail player stats.
- Do not break historical materialization.
- Do not query RCON directly from the frontend.
- Do not depend on server #03.
- Do not show misleading team colors if team is unknown.
- Do not show fake players.

## Implementation Requirements

### 1. RCA first

- Inspect the current `/api/current-match/players` response.
- Determine whether each player row includes team or enough information to infer team safely.
- Compare CSS/classes used by the historical match detail page for team coloring.

### 2. Backend data contract

If player rows already include reliable team values:

- Preserve the existing endpoint and document available team fields.

If team values exist in storage but are not exposed:

- Add normalized team fields to each player row, for example:
  - `team`
  - `team_label`
  - `team_side`
- Use only values supported by AdminLog/current data.

If team is unknown:

- Return null/unknown.
- Do not guess.

### 3. Frontend rendering

- Update the current-match player stats section so rows/cards are styled by team:
  - Allied/US/Soviet/Commonwealth/etc. side should use the same or consistent allied styling.
  - Axis/Germany side should use the same or consistent axis styling.
  - Unknown team should use neutral styling.
- Reuse historical detail team classes if possible.
- If historical detail uses existing CSS modifiers, prefer them over creating conflicting styles.

### 4. Visual requirements

- Player name should be readable.
- Team color should be visible but not overwhelming.
- Team badge/label may be shown if useful.
- Partial/event-derived confidence must remain visible.
- The section should not look like a final historical table unless data is complete.

### 5. Sorting

- Preserve current sorting if implemented:
  - kills descending
  - deaths ascending
  - name
- If not implemented, add stable sorting consistent with current endpoint.

### 6. Empty state

If no player data exists:

- Show: "Todavia no hay estadisticas fiables de jugadores para esta partida."

### 7. Partial state

If stats are AdminLog-derived:

- Show: "Estadisticas parciales derivadas de eventos recientes."
- Do not imply this is the complete roster.

### 8. Tests

If backend changes are made, add/update focused tests for:

- team fields are projected when available
- unknown team remains unknown/neutral
- no raw AdminLog exposure
- unsupported server rejection still works
- partial/event-derived metadata is preserved

### 9. Validation

- Run `python -m compileall backend/app` if backend changed.
- Run focused backend tests if changed.
- Run `node --check frontend/assets/js/partida-actual.js`.
- Run `git diff --check`.

## Manual Verification Steps

- Call `Invoke-RestMethod "http://localhost:8000/api/current-match/players?server=comunidad-hispana-01" | ConvertTo-Json -Depth 20`.
- Call `Invoke-RestMethod "http://localhost:8000/api/current-match/players?server=comunidad-hispana-02" | ConvertTo-Json -Depth 20`.
- Verify player rows include team/side data when available or unknown/null when not.
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
- Verify live player/stat rows are colored by team when team is known.
- Verify unknown-team players use neutral styling.
- Verify the section clearly indicates partial/event-derived stats.
- Verify no fake complete roster is implied.
- Verify historical match detail player colors still work.

## Expected Outcome

The current-match player/stat section uses team-aware colors consistent with the historical detail page while remaining honest about partial/event-derived live data.

## Outcome

Document the validation performed, notable decisions, and any follow-up task that should be created instead of expanding this task.

## Change Budget

- Prefer fewer than 5 modified files.
- Prefer changes under 200 lines when feasible.
- Split the work into follow-up tasks if limits are exceeded.