rgonsal/comunidadhll
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: add current match realtime refinement tasks

Browse Source
This commit is contained in:
devRaGonSa
2026-05-21 19:37:50 +02:00
parent cd50422307
commit 370e014b59
3 changed files with 492 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

169
ai/tasks/pending/TASK-158-current-match-realtime-transport.md Normal file
View File

@@ -0,0 +1,169 @@
---
id: TASK-158
title: Current match realtime transport
status: pending
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
Document the RCA, transport decision, validation performed, load/freshness limitations, 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.

171
ai/tasks/pending/TASK-159-current-match-feed-rollback-and-weapon-icons.md Normal file
View File

@@ -0,0 +1,171 @@
---
id: TASK-159
title: Current match feed rollback and weapon icons
status: pending
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
Document the visual RCA, icon discovery/mapping decision, validation performed, 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.

152
ai/tasks/pending/TASK-160-home-server-card-bottom-actions.md Normal file
View File

@@ -0,0 +1,152 @@
---
id: TASK-160
title: Home server card bottom actions
status: pending
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
Document the structural rendering cleanup, validation performed, 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.