diff --git a/ai/tasks/pending/TASK-156-current-match-realtime-killfeed-and-home-buttons-layout.md b/ai/tasks/pending/TASK-156-current-match-realtime-killfeed-and-home-buttons-layout.md
new file mode 100644
index 0000000..4923d38
--- /dev/null
+++ b/ai/tasks/pending/TASK-156-current-match-realtime-killfeed-and-home-buttons-layout.md
@@ -0,0 +1,187 @@
+# 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.
diff --git a/ai/tasks/pending/TASK-157-current-match-player-team-colors.md b/ai/tasks/pending/TASK-157-current-match-player-team-colors.md
new file mode 100644
index 0000000..c81cbd1
--- /dev/null
+++ b/ai/tasks/pending/TASK-157-current-match-player-team-colors.md
@@ -0,0 +1,169 @@
+# 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.