feat: refine current match live feed
This commit is contained in:
devRaGonSa
@@ -0,0 +1,203 @@
|
||||
# TASK-156 - Current match realtime killfeed and home buttons layout
|
||||
|
||||
Status: done
|
||||
|
||||
## Goal
|
||||
|
||||
Refine the current-match kill feed into a real-time FPS-style panel and make the home server card buttons sit at the bottom-right aligned with the map card, without changing unrelated layout.
|
||||
|
||||
## Background
|
||||
|
||||
The current-match page already has a compact kill feed overlay implemented in `frontend/assets/js/partida-actual.js` and related CSS.
|
||||
|
||||
The current visual direction is closer to the goal, but the desired behavior is now more specific:
|
||||
|
||||
- The feed should feel like a real-time FPS killfeed screen.
|
||||
- It should not look like a static list of historical events.
|
||||
- Each event should show only:
|
||||
- killer
|
||||
- weapon icon or compact weapon label
|
||||
- victim
|
||||
- The feed should behave like a small rectangular live panel.
|
||||
- Events should fill from top to bottom in three visual columns.
|
||||
- As new events arrive, old events should visually shift left and eventually disappear.
|
||||
- The visible feed must be capped and must not grow indefinitely.
|
||||
- Repeated polling must not duplicate events or cause visual flicker.
|
||||
|
||||
There is also a small home page layout request:
|
||||
|
||||
- In the home server cards, only the "Historico" and "Partida actual" buttons should remain.
|
||||
- Those buttons should sit lower, at the bottom-right, aligned with the map card height.
|
||||
- Do not change anything else in the home layout.
|
||||
|
||||
Current user-observed issues:
|
||||
|
||||
- The kill feed is still too much like a list rather than a real-time screen.
|
||||
- The home server card buttons are still too high and leave unused empty space in the bottom-right corner.
|
||||
|
||||
## Files to Read First
|
||||
|
||||
- `AGENTS.md`
|
||||
- `ai/repo-context.md`
|
||||
- `ai/architecture-index.md`
|
||||
- `frontend/partida-actual.html`
|
||||
- `frontend/assets/js/partida-actual.js`
|
||||
- `frontend/assets/js/main.js`
|
||||
|
||||
Inspect the current-match kill feed behavior, current polling/deduplication state, relevant current-match CSS, and the home server card action markup before changing code.
|
||||
|
||||
## 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
|
||||
- `frontend/assets/css/styles.css` or home CSS for the server card button alignment
|
||||
- `frontend/assets/js/main.js` only if the button markup still needs cleanup
|
||||
- local weapon icon/fallback assets if necessary
|
||||
- focused frontend validation
|
||||
|
||||
## Constraints - DO NOT BREAK
|
||||
|
||||
- Do not break `/api/current-match/kills`.
|
||||
- Do not expose raw AdminLog lines.
|
||||
- Do not fabricate kill events.
|
||||
- Do not show stale kills as live kills.
|
||||
- Do not query RCON directly from the frontend.
|
||||
- Do not break the current-match scoreboard/header.
|
||||
- Do not break the historical page.
|
||||
- Do not break historical match detail pages.
|
||||
- Do not depend on server #03.
|
||||
- Do not add external/CDN image dependencies.
|
||||
- Do not reintroduce the home card "Scoreboard publico" button.
|
||||
- Do not change the home server card content except button placement/layout if not strictly needed.
|
||||
- Keep current public scoreboard URLs trusted and without `/games`.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### 1. Current-match kill feed layout
|
||||
|
||||
- Replace any remaining card/list feel with a compact rectangular "live feed screen".
|
||||
- The feed should visually fit in a bounded panel.
|
||||
- It should not expand vertically without limit.
|
||||
- It should show a maximum number of events, for example 12 or 15.
|
||||
|
||||
### 2. Event rendering
|
||||
|
||||
Each event must show only:
|
||||
|
||||
- killer name
|
||||
- weapon icon or compact weapon badge
|
||||
- victim name
|
||||
|
||||
Avoid noisy timestamp display in the main row unless it is subtle or useful.
|
||||
|
||||
### 3. Three-column live flow
|
||||
|
||||
- Desktop layout must visually use three columns.
|
||||
- Events should fill top-to-bottom and then across columns in a predictable way.
|
||||
- Newer events should be visually prioritized.
|
||||
- Older events should move/disappear as the capped list updates.
|
||||
- On tablet/mobile, fall back safely to two columns or one column.
|
||||
|
||||
### 4. Real-time behavior
|
||||
|
||||
- Preserve `event_id` deduplication.
|
||||
- Do not duplicate rows on polling.
|
||||
- Avoid full-panel flicker every poll.
|
||||
- Keep already-rendered events stable when no new events arrive.
|
||||
- Add/remove events cleanly when the cap is exceeded.
|
||||
|
||||
### 5. Weapon display
|
||||
|
||||
- Use local/fallback icons or compact glyph badges.
|
||||
- Include mappings for currently seen examples:
|
||||
- `M1 GARAND`
|
||||
- `MP40`
|
||||
- `M1A1 THOMPSON`
|
||||
- `UNKNOWN`
|
||||
- Unknown weapons should show a generic fallback, not broken image.
|
||||
- Do not use external URLs.
|
||||
|
||||
### 6. Teamkill
|
||||
|
||||
- Teamkills must remain distinguishable but compact.
|
||||
- Do not let teamkill badges dominate the layout.
|
||||
|
||||
### 7. Feed copy
|
||||
|
||||
- If there are no current events: "Todavia no se han detectado bajas en esta partida."
|
||||
- If events are current/open-window: "Bajas detectadas en la partida actual."
|
||||
- If events are fresh but partial: "Cobertura parcial desde AdminLog reciente."
|
||||
- If stale/no current events: "Sin bajas recientes asociadas a la partida actual."
|
||||
|
||||
### 8. Home server card layout
|
||||
|
||||
- Ensure only two per-server buttons are visible:
|
||||
- "Historico"
|
||||
- "Partida actual"
|
||||
- Remove/hide "Scoreboard publico" from the home server card.
|
||||
- Move the two buttons down to the lower-right of the card, aligned visually with the map card at the bottom-left.
|
||||
- Keep the map card compact and do not enlarge it.
|
||||
- Do not change the rest of the home content/layout.
|
||||
- Preserve responsive behavior.
|
||||
|
||||
### 9. Validation
|
||||
|
||||
- Run `node --check frontend/assets/js/partida-actual.js`.
|
||||
- Run `node --check frontend/assets/js/main.js` if modified.
|
||||
- Run `git diff --check`.
|
||||
- Rebuild frontend if needed.
|
||||
|
||||
## Manual Verification Steps
|
||||
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
|
||||
- Verify the kill feed looks like a compact rectangular live overlay.
|
||||
- Verify each event row shows:
|
||||
- killer
|
||||
- weapon icon/badge
|
||||
- victim
|
||||
- Verify the feed uses three columns on desktop.
|
||||
- Verify older events disappear instead of growing endlessly.
|
||||
- Verify repeated polling does not duplicate events.
|
||||
- Verify the feed does not flicker on every refresh.
|
||||
- Verify unknown weapons use a fallback.
|
||||
- Verify no raw AdminLog line is displayed.
|
||||
- Open the home page: `http://localhost:8080/`.
|
||||
- Verify each server card shows only:
|
||||
- Historico
|
||||
- Partida actual
|
||||
- Verify those buttons sit at the bottom-right, visually aligned with the map card.
|
||||
- Verify no other home page layout area changes unexpectedly.
|
||||
|
||||
## Expected Outcome
|
||||
|
||||
The current-match kill feed behaves like a compact real-time combat overlay, and the home server card action buttons are cleanly aligned bottom-right with only "Historico" and "Partida actual" visible.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Kept the existing `event_id`-based killfeed refresh path and changed only its
|
||||
rendering surface: the capped 15-event panel now reads as a bounded combat
|
||||
screen with three desktop columns, while smaller breakpoints remain bounded.
|
||||
- Removed the home server-card public-scoreboard action from the hydrated markup
|
||||
and left the remaining `Historico` / `Partida actual` actions aligned by the
|
||||
existing status-column layout.
|
||||
- Validated with:
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `node --check frontend/assets/js/main.js`
|
||||
- `git diff --check`
|
||||
- `docker compose up -d --build frontend`
|
||||
- live endpoint checks for `/api/current-match/kills` on Comunidad Hispana
|
||||
`#01` and `#02`
|
||||
- rendered Chrome headless screenshots of the home page, current-match `#01`
|
||||
desktop view and current-match `#02` mobile empty-state view
|
||||
- The in-app Browser automation runtime was not callable after tool discovery,
|
||||
so rendered validation used local headless Chrome against the task URLs.
|
||||
|
||||
## 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.
|
||||
197
ai/tasks/done/TASK-157-current-match-player-team-colors.md
Normal file
197
ai/tasks/done/TASK-157-current-match-player-team-colors.md
Normal file
@@ -0,0 +1,197 @@
|
||||
# TASK-157 - Current match player team colors
|
||||
|
||||
Status: done
|
||||
|
||||
## 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
|
||||
|
||||
- RCA found no backend contract gap: a live
|
||||
`/api/current-match/players?server=comunidad-hispana-01` response observed
|
||||
before the validation rebuild already exposed AdminLog-derived `team` values
|
||||
such as `Allies` and `Axis`; unknown values remain handled by the existing
|
||||
frontend neutral path.
|
||||
- Reused the historical detail player row and team badge CSS modifiers from
|
||||
`historico-scoreboard-detail.css` in the current-match player table instead
|
||||
of adding a parallel style system.
|
||||
- Included `team` in the visible player-table signature so a future team update
|
||||
can rerender an already-visible row without changing its stats.
|
||||
- Validated with:
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `git diff --check`
|
||||
- `docker compose up -d --build frontend`
|
||||
- live `/api/current-match/players` checks on Comunidad Hispana `#01` and
|
||||
`#02`
|
||||
- rendered Chrome headless current-match validation for the available player
|
||||
empty state after the backend restart
|
||||
- served-script check confirming the historical row and badge modifiers are
|
||||
present in `frontend/assets/js/partida-actual.js`
|
||||
- The final rendered validation window had no current player rows after the
|
||||
backend rebuild, so known-team colors were validated from the observed live
|
||||
payload contract plus the reused historical class mapping rather than from a
|
||||
live colored-row screenshot.
|
||||
- Repository-level follow-up validation ran
|
||||
`powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1`.
|
||||
It returned exit code `0`, but its output also printed a historical SQLite
|
||||
`database disk image is malformed` traceback after the pass banner; that
|
||||
historical storage issue is outside this frontend task scope.
|
||||
|
||||
## 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.
|
||||
193
ai/tasks/done/TASK-158-current-match-realtime-transport.md
Normal file
193
ai/tasks/done/TASK-158-current-match-realtime-transport.md
Normal file
@@ -0,0 +1,193 @@
|
||||
---
|
||||
id: TASK-158
|
||||
title: Current match realtime transport
|
||||
status: done
|
||||
type: backend
|
||||
team: Backend Senior
|
||||
supporting_teams: [Frontend Senior]
|
||||
roadmap_item: foundation
|
||||
priority: high
|
||||
---
|
||||
|
||||
# TASK-158 - Current match realtime transport
|
||||
|
||||
## Goal
|
||||
|
||||
Implement a real-time or near-real-time update strategy for the current-match page, prioritizing the kill feed and then current match metadata/player stats.
|
||||
|
||||
## Background
|
||||
|
||||
The current-match page currently refreshes through polling. In `frontend/assets/js/partida-actual.js`, the current interval is:
|
||||
|
||||
`CURRENT_MATCH_POLL_INTERVAL_MS = 30 * 1000`
|
||||
|
||||
The user explicitly rejected this behavior:
|
||||
|
||||
- "He dicho que se actualice en vivo y no cada 20 segundos"
|
||||
|
||||
The page should behave much closer to real time, especially for the kill feed. A 20/30-second refresh is too slow for a live combat screen.
|
||||
|
||||
Current endpoints:
|
||||
|
||||
- `GET /api/current-match?server=...`
|
||||
- `GET /api/current-match/kills?server=...`
|
||||
- `GET /api/current-match/players?server=...`
|
||||
|
||||
## Files to Read First
|
||||
|
||||
- `AGENTS.md`
|
||||
- `ai/repo-context.md`
|
||||
- `ai/architecture-index.md`
|
||||
- `frontend/assets/js/partida-actual.js`
|
||||
- `backend/app/routes.py`
|
||||
- `backend/app/rcon_admin_log_storage.py`
|
||||
|
||||
Inspect the current frontend refresh flow, current-match route payloads, kill feed read model, trusted server validation, and recent AdminLog materialization cadence before changing code.
|
||||
|
||||
## Expected Files to Modify
|
||||
|
||||
Allowed changes:
|
||||
|
||||
- `backend/app/routes.py`
|
||||
- `backend/app/payloads.py`
|
||||
- `backend/app/rcon_admin_log_storage.py`
|
||||
- backend helper/read-model files if needed
|
||||
- `frontend/assets/js/partida-actual.js`
|
||||
- `frontend/partida-actual.html` if needed
|
||||
- focused tests
|
||||
|
||||
## Constraints - DO NOT BREAK
|
||||
|
||||
- Do not query RCON directly from the frontend.
|
||||
- Do not expose raw AdminLog lines.
|
||||
- Do not fabricate events.
|
||||
- Do not show stale kills as live kills.
|
||||
- Do not depend on server #03.
|
||||
- Do not break existing REST endpoints.
|
||||
- Do not break historical pages or historical match detail pages.
|
||||
- Keep trusted server validation.
|
||||
- Keep current public scoreboard URLs without `/games`.
|
||||
- Avoid overloading the backend/RCON/AdminLog pipeline.
|
||||
- Commit and push after implementation.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### 1. RCA first
|
||||
|
||||
- Document current update flow in TASK done notes.
|
||||
- Confirm which parts are safe to update at high frequency:
|
||||
- kill feed
|
||||
- player stats
|
||||
- match metadata/scoreboard
|
||||
- Identify whether the backend has access to sufficiently fresh AdminLog data without calling RCON per browser poll.
|
||||
|
||||
### 2. Preferred transport
|
||||
|
||||
Evaluate and implement the safest available option:
|
||||
|
||||
- Server-Sent Events (SSE) endpoint for live kill events, OR
|
||||
- short polling for killfeed every 1-2 seconds with ETag/since cursor/last_event_id, OR
|
||||
- another minimal transport that gives near-real-time updates without duplicating events.
|
||||
|
||||
Prefer SSE if it is simple and safe in the current backend stack.
|
||||
|
||||
If SSE is not appropriate, implement short polling with cursor semantics.
|
||||
|
||||
### 3. Kill feed endpoint behavior
|
||||
|
||||
Add support for incremental fetching:
|
||||
|
||||
- `since_event_id` or since timestamp/server_time
|
||||
- `limit`
|
||||
- server slug
|
||||
- trusted server validation
|
||||
|
||||
The endpoint must return only new events where possible.
|
||||
|
||||
### 4. Frontend behavior
|
||||
|
||||
- Remove dependency on a 20/30-second interval for kill feed updates.
|
||||
- Kill feed should update in near-real-time.
|
||||
- Avoid overlapping requests.
|
||||
- Preserve `event_id` deduplication.
|
||||
- Do not re-render the whole panel if no new events arrived.
|
||||
- Keep a capped event buffer.
|
||||
|
||||
### 5. Match metadata and player stats
|
||||
|
||||
- These do not need to update every second.
|
||||
- Keep a slower safe refresh for scoreboard/player stats if needed, for example 10-30 seconds.
|
||||
- The kill feed must be faster than metadata refresh.
|
||||
|
||||
### 6. Failure/reconnect
|
||||
|
||||
- If SSE is used, implement reconnect behavior.
|
||||
- If short polling is used, handle transient errors without breaking the page.
|
||||
- Show a small stale/error state only when needed.
|
||||
|
||||
### 7. Backend load
|
||||
|
||||
- Do not query expensive RCON calls per browser every second.
|
||||
- Prefer reading already persisted/recent AdminLog materialized data.
|
||||
- If a live AdminLog ingestion cadence is insufficient, document it instead of hiding the limitation.
|
||||
|
||||
## Validation
|
||||
|
||||
Run:
|
||||
|
||||
- `python -m compileall backend/app`
|
||||
- focused backend tests if added/updated
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `git diff --check`
|
||||
|
||||
Before completing the task also confirm that `git diff --name-only` matches the expected scope.
|
||||
|
||||
## Manual Verification Steps
|
||||
|
||||
- Rebuild backend and frontend.
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
|
||||
- During an active match, verify new kill events appear without waiting 20/30 seconds.
|
||||
- Verify repeated updates do not duplicate events.
|
||||
- Verify no raw AdminLog lines appear.
|
||||
- Verify stale events are not displayed as live.
|
||||
- Verify metadata/scoreboard remains stable and does not flicker.
|
||||
- Verify backend logs do not show excessive RCON/API pressure.
|
||||
|
||||
## Expected Outcome
|
||||
|
||||
The current-match kill feed updates in near-real-time, without depending on the existing 30-second page refresh cycle.
|
||||
|
||||
## Outcome
|
||||
|
||||
RCA:
|
||||
|
||||
- The current page used one `30s` interval in `frontend/assets/js/partida-actual.js` for current-match metadata, player stats and the kill feed together.
|
||||
- The kill feed read path is already safe for higher-frequency reads because it queries normalized persisted `rcon_admin_log_events` rows through `/api/current-match/kills`; it does not query RCON from the browser or expose raw AdminLog lines.
|
||||
- Current match metadata can still call live RCON through the existing payload path, and player stats aggregate the kill feed read model, so those surfaces remain on the slower refresh path.
|
||||
|
||||
Transport decision:
|
||||
|
||||
- Implemented incremental short polling for the kill feed instead of SSE. The backend is still the standard-library JSON route stack, while the existing persisted read model can cheaply support a cursor.
|
||||
- `/api/current-match/kills` now accepts `since_event_id` plus the existing `server` and `limit` inputs. Trusted server validation remains in `routes.py`.
|
||||
- The frontend polls kill-feed rows every `1500ms`, sends the latest event id cursor after the first load, deduplicates by `event_id`, caps the in-memory visible buffer and avoids overlapping kill-feed requests. Metadata and player stats keep the existing `30s` refresh cadence.
|
||||
|
||||
Validation performed:
|
||||
|
||||
- `python -m compileall backend/app`
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `git diff --check`
|
||||
- Ran a direct Python smoke check for `list_current_match_kill_feed(..., since_event_id=...)` with temporary AdminLog rows after the focused pytest command could not run.
|
||||
- Attempted focused backend tests with `python -m pytest backend/tests/test_current_match_payload.py backend/tests/test_rcon_admin_log_storage.py`; this environment failed with `No module named pytest`.
|
||||
- Reviewed `git diff --name-only`; task-owned code changes are limited to the allowed current-match backend/frontend files plus the focused storage test and this task transition. The worktree already contained frontend and prior task changes from `TASK-156`/`TASK-157`.
|
||||
|
||||
Load and freshness limit:
|
||||
|
||||
- Browser polling now reads persisted AdminLog rows rather than issuing per-browser RCON calls.
|
||||
- New kill visibility is still bounded by how quickly `app.rcon_historical_worker` or manual AdminLog ingestion persists fresh AdminLog rows. The current documented worker example is a `120s` loop, so operations may need a follow-up cadence decision if that persisted source is not fresh enough for the desired live screen.
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,188 @@
|
||||
---
|
||||
id: TASK-159
|
||||
title: Current match feed rollback and weapon icons
|
||||
status: done
|
||||
type: frontend
|
||||
team: Frontend Senior
|
||||
supporting_teams: [Disenador grafico, Experto en interfaz]
|
||||
roadmap_item: foundation
|
||||
priority: high
|
||||
---
|
||||
|
||||
# TASK-159 - Current match feed rollback and weapon icons
|
||||
|
||||
## Goal
|
||||
|
||||
Rollback/refactor the current killfeed visual layout to the previous accepted live feed style and integrate local weapon icons where available.
|
||||
|
||||
## Background
|
||||
|
||||
The latest compact three-column killfeed implementation is not accepted visually. The user wants to return to the previous live feed screen direction and then improve it.
|
||||
|
||||
User feedback:
|
||||
|
||||
- "Quiero volver a la pantalla de feed de la partida en vivo de antes, esta no me convence"
|
||||
- The desired feed should still be a live combat screen, but not the current overly table/grid-like layout.
|
||||
- Weapon icons were manually added to the repository for testing and should be reused.
|
||||
|
||||
Current issue:
|
||||
|
||||
The current killfeed visually feels too much like a table/grid and not enough like a readable live combat feed. The user wants the previous feed visual style back, then use weapon icons.
|
||||
|
||||
## Files to Read First
|
||||
|
||||
- `AGENTS.md`
|
||||
- `ai/repo-context.md`
|
||||
- `ai/architecture-index.md`
|
||||
- `frontend/partida-actual.html`
|
||||
- `frontend/assets/js/partida-actual.js`
|
||||
- relevant current-match CSS and `frontend/assets/img/weapons/`
|
||||
|
||||
Inspect git history/diff around the feed changes before choosing whether to restore prior markup or intentionally recreate the previous direction.
|
||||
|
||||
## 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 CSS
|
||||
- `frontend/assets/img/weapons/*` only if renaming/organizing existing local icons is necessary
|
||||
- no backend changes unless weapon normalization is strictly needed
|
||||
|
||||
## Constraints - DO NOT BREAK
|
||||
|
||||
- Do not break `/api/current-match/kills`.
|
||||
- Do not expose raw AdminLog lines.
|
||||
- Do not fabricate kill events.
|
||||
- Do not show stale kills as live kills.
|
||||
- Do not query RCON directly from the frontend.
|
||||
- Do not break the current-match scoreboard/header.
|
||||
- Do not break the player stats section.
|
||||
- Do not break historical pages.
|
||||
- Do not depend on server #03.
|
||||
- Do not hotlink external weapon images.
|
||||
- Use local weapon icon assets only.
|
||||
- Unknown weapons must have a clean fallback.
|
||||
- Commit and push after implementation.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### 1. RCA first
|
||||
|
||||
- Identify the previous feed layout/style before TASK-156/TASK-157 changes using git history/diff.
|
||||
- Identify what parts of the previous style the user likely preferred:
|
||||
- card readability
|
||||
- vertical event readability
|
||||
- less table/grid feel
|
||||
- Document this in TASK done notes.
|
||||
|
||||
### 2. Rollback/refactor visual style
|
||||
|
||||
- Restore the previous feed screen style or recreate it intentionally.
|
||||
- It should be readable and live-oriented.
|
||||
- It should not look like the current table-like three-column grid.
|
||||
- Keep the feed bounded and capped; do not allow infinite growth.
|
||||
- Keep deduplication.
|
||||
|
||||
### 3. Event content
|
||||
|
||||
Each event should show:
|
||||
|
||||
- killer
|
||||
- weapon icon
|
||||
- victim
|
||||
|
||||
Optional timestamp may be shown only if visually subtle.
|
||||
|
||||
### 4. Weapon icon discovery
|
||||
|
||||
- Inspect `frontend/assets/img/weapons` or any newly added weapon icon folder.
|
||||
- Reuse local icons the user added.
|
||||
- Do not create external dependencies.
|
||||
- If filenames are inconsistent, add a safe mapping instead of renaming unless renaming is clearly cleaner.
|
||||
|
||||
### 5. Weapon icon mapping
|
||||
|
||||
Add mapping for at least:
|
||||
|
||||
- `M1 GARAND`
|
||||
- `MP40`
|
||||
- `M1A1 THOMPSON`
|
||||
- `GEWEHR 43`
|
||||
- `MG42`
|
||||
- `UNKNOWN`
|
||||
- generic fallback
|
||||
|
||||
Also support simple normalization:
|
||||
|
||||
- uppercase/lowercase differences
|
||||
- spaces/hyphens
|
||||
- common AdminLog weapon strings
|
||||
|
||||
### 6. Visual behavior
|
||||
|
||||
- Events should appear as compact readable live-feed entries.
|
||||
- Avoid the current big empty table-like columns.
|
||||
- Avoid full panel flicker.
|
||||
- Limit visible entries, for example 10-15.
|
||||
- Older events should disappear when the cap is exceeded.
|
||||
|
||||
### 7. Empty states
|
||||
|
||||
- If no current events: "Todavía no se han detectado bajas en esta partida."
|
||||
- If stale/no current events: "Sin bajas recientes asociadas a la partida actual."
|
||||
|
||||
## Validation
|
||||
|
||||
Run:
|
||||
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `git diff --check`
|
||||
- rebuild frontend
|
||||
|
||||
Before completing the task also confirm that `git diff --name-only` matches the expected scope.
|
||||
|
||||
## Manual Verification Steps
|
||||
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
|
||||
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
|
||||
- Verify the feed no longer looks like the current table/grid.
|
||||
- Verify it resembles the previous live feed screen direction.
|
||||
- Verify each event shows killer, weapon icon, victim.
|
||||
- Verify unknown weapons use fallback.
|
||||
- Verify local weapon icons load correctly.
|
||||
- Verify repeated updates do not duplicate rows.
|
||||
- Verify stale events are not shown as live.
|
||||
- Verify the player stats section still works.
|
||||
|
||||
## Expected Outcome
|
||||
|
||||
The current-match feed returns to the previous preferred live-feed visual direction while using the newly added local weapon icons.
|
||||
|
||||
## Outcome
|
||||
|
||||
Visual RCA:
|
||||
|
||||
- Git history before the compact feed change showed a vertical `historical-match-card` list with one readable event per row/card. The rejected version introduced a fixed multi-column killfeed surface that reads like a grid/table.
|
||||
- The feed was refactored back to a vertical card-like list while keeping the current live buffer, deduplication and no-flicker signature guard.
|
||||
|
||||
Weapon icon decision:
|
||||
|
||||
- Reused local assets already present under `frontend/assets/img/weapons/`.
|
||||
- `partida-actual.js` maps normalized AdminLog weapon names for `M1 GARAND`, `MP40`, `M1A1 THOMPSON`, `GEWEHR 43`, `MG42` and aliases to local PNGs.
|
||||
- Unknown/unmapped weapons keep their label for tooltip/accessibility and render a compact local fallback marker instead of hotlinking assets.
|
||||
|
||||
Validation performed:
|
||||
|
||||
- `node --check frontend/assets/js/partida-actual.js`
|
||||
- `git diff --check`
|
||||
- `docker compose build frontend`
|
||||
- Reviewed the history diff for the prior accepted feed direction and inspected local weapon asset filenames.
|
||||
- Rendered Browser verification was attempted through the required Browser workflow but blocked because the Browser JavaScript execution tool was not exposed in this session after tool discovery.
|
||||
|
||||
## 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.
|
||||
164
ai/tasks/done/TASK-160-home-server-card-bottom-actions.md
Normal file
164
ai/tasks/done/TASK-160-home-server-card-bottom-actions.md
Normal file
@@ -0,0 +1,164 @@
|
||||
---
|
||||
id: TASK-160
|
||||
title: Home server card bottom actions
|
||||
status: done
|
||||
type: frontend
|
||||
team: Frontend Senior
|
||||
supporting_teams: [Experto en interfaz]
|
||||
roadmap_item: foundation
|
||||
priority: high
|
||||
---
|
||||
|
||||
# TASK-160 - Home server card bottom actions
|
||||
|
||||
## Goal
|
||||
|
||||
Cleanly restructure the home server card action layout so only Historico and Partida actual render, positioned bottom-right aligned with the map card, without changing unrelated UI.
|
||||
|
||||
## Background
|
||||
|
||||
The home page server cards are rendered from `frontend/assets/js/main.js`.
|
||||
|
||||
Current user feedback:
|
||||
|
||||
- The home card buttons are still too high.
|
||||
- The user wants the buttons moved "dos pasos al div de abajo con el mapa".
|
||||
- The buttons must be located at the far right in the lower area, aligned with the map card.
|
||||
- The layout should be more compact.
|
||||
- Do not touch anything else.
|
||||
|
||||
Current known issue:
|
||||
|
||||
- `renderServerAction(server)` in `frontend/assets/js/main.js` still renders "Scoreboard publico".
|
||||
- CSS/HTML workarounds have been used to hide/rename buttons.
|
||||
- The user wants only:
|
||||
- Historico
|
||||
- Partida actual
|
||||
|
||||
## Files to Read First
|
||||
|
||||
- `AGENTS.md`
|
||||
- `ai/repo-context.md`
|
||||
- `ai/architecture-index.md`
|
||||
- `frontend/index.html`
|
||||
- `frontend/assets/js/main.js`
|
||||
- `frontend/assets/css/styles.css`
|
||||
|
||||
Inspect the rendered server card structure, quickfact/map markup, trusted action URL mapping, and any existing inline or stylesheet button workarounds before changing code.
|
||||
|
||||
## Expected Files to Modify
|
||||
|
||||
Allowed changes:
|
||||
|
||||
- `frontend/assets/js/main.js`
|
||||
- `frontend/assets/css/styles.css`
|
||||
- `frontend/index.html` only to remove previous inline CSS workarounds if present
|
||||
- no backend changes
|
||||
- no tests unless needed
|
||||
- node validation
|
||||
|
||||
## Constraints - DO NOT BREAK
|
||||
|
||||
- Do not change backend.
|
||||
- Do not change current-match page.
|
||||
- Do not change historical page behavior.
|
||||
- Do not change server polling logic.
|
||||
- Do not reintroduce Scoreboard publico on home server cards.
|
||||
- Do not remove trusted URL mappings if used elsewhere unless unused.
|
||||
- Do not alter the rest of the home page layout/content.
|
||||
- Preserve responsive behavior.
|
||||
- Commit and push after implementation.
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### 1. Remove structural rendering of Scoreboard publico
|
||||
|
||||
`renderServerAction(server)` should only output:
|
||||
|
||||
- Historico
|
||||
- Partida actual
|
||||
|
||||
### 2. Rename the rendered history action
|
||||
|
||||
Rename "Nuestro historico" to "Historico" in the rendered markup.
|
||||
|
||||
### 3. Avoid CSS-only hide/rename hacks
|
||||
|
||||
- Remove old CSS workarounds that hide first button or replace text through pseudo-elements if present.
|
||||
- Make the JS markup itself correct.
|
||||
|
||||
### 4. Move buttons to the lower-right area
|
||||
|
||||
- The map quickfact card remains lower-left.
|
||||
- The action buttons should be in the same lower row/block, aligned far right.
|
||||
- Avoid large empty bottom-right space.
|
||||
- Keep card height compact.
|
||||
|
||||
### 5. Suggested structure
|
||||
|
||||
- Card top: eyebrow, server name, status/population.
|
||||
- Card bottom row: map card left, action buttons right.
|
||||
- Do not make the map card huge.
|
||||
- Buttons should not float in the middle of the card.
|
||||
|
||||
### 6. Responsive behavior
|
||||
|
||||
- On desktop, bottom row is two columns:
|
||||
- map left
|
||||
- actions right
|
||||
- On mobile/narrow widths, stack safely:
|
||||
- map
|
||||
- actions
|
||||
|
||||
## Validation
|
||||
|
||||
Run:
|
||||
|
||||
- `node --check frontend/assets/js/main.js`
|
||||
- `git diff --check`
|
||||
- rebuild frontend
|
||||
|
||||
Before completing the task also confirm that `git diff --name-only` matches the expected scope.
|
||||
|
||||
## Manual Verification Steps
|
||||
|
||||
- Open `http://localhost:8080/`.
|
||||
- Verify each server card shows only:
|
||||
- Historico
|
||||
- Partida actual
|
||||
- Verify Scoreboard publico is not rendered.
|
||||
- Verify buttons are bottom-right aligned with the map card.
|
||||
- Verify map card remains compact.
|
||||
- Verify card layout is not broken on narrow viewport.
|
||||
- Verify Historico opens:
|
||||
- `historico.html?server=comunidad-hispana-01`
|
||||
- `historico.html?server=comunidad-hispana-02`
|
||||
- Verify Partida actual opens:
|
||||
- `partida-actual.html?server=comunidad-hispana-01`
|
||||
- `partida-actual.html?server=comunidad-hispana-02`
|
||||
|
||||
## Expected Outcome
|
||||
|
||||
The home server cards have a clean structural layout with only Historico and Partida actual positioned at the lower-right aligned with the map card.
|
||||
|
||||
## Outcome
|
||||
|
||||
Structural cleanup:
|
||||
|
||||
- Home server card actions now live in a dedicated bottom row beside the map quickfact rather than inside the status column.
|
||||
- The rendered card action markup keeps only `Historico` and `Partida actual`; trusted URL mappings stay intact for those actions.
|
||||
- Removed the inline server-card layout workaround from `frontend/index.html` and moved the bottom-row layout rules into `frontend/assets/css/styles.css`, with a stacked narrow layout.
|
||||
|
||||
Validation performed:
|
||||
|
||||
- `node --check frontend/assets/js/main.js`
|
||||
- `git diff --check`
|
||||
- `docker compose build frontend`
|
||||
- Checked the existing local frontend and backend endpoints were serving on `127.0.0.1:8080` and `127.0.0.1:8000`.
|
||||
- Rendered Browser verification was attempted through the required Browser workflow but blocked because the Browser JavaScript execution tool was not exposed in this session after tool discovery.
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user