feat: refine current match live feed
This commit is contained in:
devRaGonSa
@@ -1,187 +0,0 @@
|
||||
# TASK-156 - Current match realtime killfeed and home buttons layout
|
||||
|
||||
Status: pending
|
||||
|
||||
## 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
|
||||
|
||||
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.
|
||||
@@ -1,169 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,169 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,171 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,152 +0,0 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user