Ajustes UI
This commit is contained in:
57
ai/tasks/done/TASK-018-hero-layout-rebalance.md
Normal file
57
ai/tasks/done/TASK-018-hero-layout-rebalance.md
Normal file
@@ -0,0 +1,57 @@
|
||||
# TASK-018-hero-layout-rebalance
|
||||
|
||||
## Goal
|
||||
Reequilibrar la composición visual del hero de la landing de HLL Vietnam para darle más impacto, reducir sensación de vacío vertical y mejorar la relación entre logo, titular, subtítulo y CTA principal.
|
||||
|
||||
## Context
|
||||
La landing ya tiene una base visual sólida, pero el hero actual presenta varios puntos de mejora: demasiado espacio vertical, un titular muy dominante partido en varias líneas, un logo con menos protagonismo del deseado y una composición general menos potente que el resto de la página. Esta task debe centrarse únicamente en recomponer el bloque principal para que se perciba como una cabecera premium, más compacta y más cinematográfica, sin cambiar el alcance funcional actual.
|
||||
|
||||
## Steps
|
||||
1. Revisar la composición actual del hero en la landing.
|
||||
2. Evaluar el equilibrio visual entre:
|
||||
- logo
|
||||
- eyebrow o etiqueta superior
|
||||
- título principal
|
||||
- subtítulo o texto descriptivo
|
||||
- chip de estado backend si aplica
|
||||
- CTA principal
|
||||
3. Reducir la sensación de vacío vertical y mejorar el ritmo del bloque.
|
||||
4. Ajustar el protagonismo del logo para que se sienta más integrado y relevante.
|
||||
5. Ajustar el titular para que mantenga fuerza, pero no rompa la composición ni monopolice toda la jerarquía visual.
|
||||
6. Reordenar o afinar espaciados, anchuras máximas y alineaciones para que el conjunto se perciba más compacto y más intencional.
|
||||
7. Mantener el hero claro, centrado en comunidad, branding y CTA.
|
||||
8. Validar que la composición siga funcionando bien en móvil y escritorio.
|
||||
9. No alterar enlaces, rutas ni comportamiento funcional existente.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/assets/js/main.js
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No cambiar la ruta del logo.
|
||||
- No cambiar el enlace del Discord.
|
||||
- No cambiar el enlace del tráiler.
|
||||
- No añadir nuevas secciones.
|
||||
- No introducir librerías nuevas.
|
||||
- No romper el fallback actual.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener la landing simple y coherente con el tono HLL Vietnam.
|
||||
|
||||
## Validation
|
||||
- El hero se siente más compacto y más fuerte visualmente.
|
||||
- El logo tiene mejor presencia relativa.
|
||||
- El titular sigue siendo potente pero está mejor equilibrado.
|
||||
- El CTA sigue siendo claro y visible.
|
||||
- La cabecera transmite más sensación de portada principal.
|
||||
- La composición sigue siendo responsive y estable.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 2 archivos modificados.
|
||||
- Preferir menos de 170 líneas cambiadas.
|
||||
56
ai/tasks/done/TASK-019-atmospheric-depth-pass.md
Normal file
56
ai/tasks/done/TASK-019-atmospheric-depth-pass.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# TASK-019-atmospheric-depth-pass
|
||||
|
||||
## Goal
|
||||
Aumentar la profundidad visual y la atmósfera general de la landing de HLL Vietnam mediante un refinamiento controlado de fondo, overlays, iluminación y separación de planos, sin recargar la interfaz ni romper su sobriedad.
|
||||
|
||||
## Context
|
||||
La paleta actual funciona y la base visual está bien encaminada, pero el fondo y el marco general aún se perciben algo planos. Hace falta una pasada de atmósfera para reforzar el tono Vietnam/táctico, mejorar la profundidad percibida y dar más cohesión al conjunto, especialmente alrededor del hero y de las secciones principales.
|
||||
|
||||
## Steps
|
||||
1. Revisar el tratamiento actual del fondo y los overlays.
|
||||
2. Evaluar cómo se perciben:
|
||||
- profundidad
|
||||
- viñeteado
|
||||
- textura ambiental
|
||||
- degradados
|
||||
- separación entre hero y secciones
|
||||
3. Refinar el sistema de fondo para aportar más atmósfera sin saturar.
|
||||
4. Aplicar mejoras controladas en:
|
||||
- overlays
|
||||
- sombras de entorno
|
||||
- iluminación indirecta
|
||||
- separación de bloques
|
||||
- sensación cinematográfica
|
||||
5. Mantener una estética oscura, militar y limpia.
|
||||
6. Evitar efectos exagerados, brillos excesivos o ruido visual.
|
||||
7. Validar que el resultado no perjudica legibilidad ni rendimiento aparente.
|
||||
8. Mantener intacto el comportamiento funcional de la landing.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/assets/css/styles.css
|
||||
- opcionalmente `frontend/index.html` si hiciera falta una envolvente mínima o ajuste estructural pequeño para soportar mejor la profundidad visual
|
||||
|
||||
## Constraints
|
||||
- No cambiar contenido funcional.
|
||||
- No añadir imágenes nuevas ni dependencias nuevas salvo que sea estrictamente innecesario.
|
||||
- No rediseñar completamente la página.
|
||||
- No tocar backend.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el tono sobrio y cinematográfico.
|
||||
|
||||
## Validation
|
||||
- La página transmite mayor profundidad visual.
|
||||
- El fondo se siente menos plano.
|
||||
- Hero y secciones se perciben mejor separados y más cohesionados.
|
||||
- La atmósfera Vietnam/táctica queda reforzada.
|
||||
- La legibilidad y claridad general se mantienen o mejoran.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 2 archivos modificados.
|
||||
- Preferir menos de 160 líneas cambiadas.
|
||||
58
ai/tasks/done/TASK-020-component-surface-polish.md
Normal file
58
ai/tasks/done/TASK-020-component-surface-polish.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# TASK-020-component-surface-polish
|
||||
|
||||
## Goal
|
||||
Pulir visualmente superficies y componentes de la landing de HLL Vietnam para mejorar calidad percibida, consistencia y acabado en tarjetas, chips, badges, contenedores y detalles de UI.
|
||||
|
||||
## Context
|
||||
La landing ya tiene una estructura visual bastante competente, pero aún puede ganar acabado en microdetalles de interfaz. El panel de servidores, las tarjetas, los chips de estado y los contenedores principales necesitan una pasada de consistencia visual para que el conjunto se sienta más refinado y más uniforme.
|
||||
|
||||
## Steps
|
||||
1. Revisar los componentes visuales actuales de la landing.
|
||||
2. Evaluar consistencia en:
|
||||
- radios
|
||||
- bordes
|
||||
- sombras
|
||||
- chips
|
||||
- badges de estado
|
||||
- tarjetas
|
||||
- barras de ocupación
|
||||
- encabezados de panel
|
||||
3. Refinar esos elementos para que compartan un lenguaje visual más sólido y coherente.
|
||||
4. Mejorar calidad percibida sin añadir complejidad innecesaria.
|
||||
5. Asegurar que el panel de servidores y los componentes de apoyo se lean mejor tanto en estado estático como hidratado por JS.
|
||||
6. Mantener clara la jerarquía entre componentes primarios y secundarios.
|
||||
7. Validar responsive y consistencia entre escritorio y móvil.
|
||||
8. No tocar el contrato del backend ni el contenido funcional de los payloads.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/assets/js/main.js
|
||||
- backend/app/payloads.py
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/assets/js/main.js
|
||||
|
||||
## Constraints
|
||||
- No cambiar endpoints.
|
||||
- No cambiar payloads backend.
|
||||
- No añadir librerías nuevas.
|
||||
- No romper el fallback estático.
|
||||
- No rediseñar completamente la landing.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el ajuste centrado en UI y acabado visual.
|
||||
|
||||
## Validation
|
||||
- Las superficies y componentes se ven más coherentes y mejor acabados.
|
||||
- Chips, badges y tarjetas tienen una presentación más limpia y consistente.
|
||||
- El panel de servidores gana claridad y calidad visual.
|
||||
- La landing mantiene su funcionamiento actual.
|
||||
- La mejora se aprecia en desktop y mobile.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 190 líneas cambiadas.
|
||||
@@ -0,0 +1,60 @@
|
||||
# TASK-043-unified-page-shell-and-section-width-system
|
||||
|
||||
## Goal
|
||||
Unificar el sistema de anchuras de la pagina para que hero, trailer y panel de servidores compartan el mismo ancho util y se perciban como parte de una misma experiencia visual, eliminando la sensacion actual de secciones con tamanos distintos.
|
||||
|
||||
## Context
|
||||
La UI actual ya funciona y muestra datos reales, pero las secciones principales no comparten una anchura consistente. Esto hace que la pagina se sienta fragmentada y reduce la sensacion de producto final. El objetivo de esta task es definir un unico sistema de shell/layout para las secciones principales y aplicarlo de forma consistente.
|
||||
|
||||
## Steps
|
||||
1. Revisar la estructura actual de shells, contenedores y max-width del frontend.
|
||||
2. Identificar diferencias de ancho entre:
|
||||
- hero
|
||||
- bloque del trailer
|
||||
- bloque de servidores
|
||||
3. Definir un unico ancho maestro para las secciones principales en desktop.
|
||||
4. Hacer que hero, trailer y panel de servidores usen el mismo carril visual principal.
|
||||
5. Ajustar margenes laterales, paddings y separacion vertical para evitar sensacion de fragmentacion.
|
||||
6. Mantener el comportamiento responsive correcto en tablet y movil.
|
||||
7. No redisenar el contenido, solo el sistema de layout y anchuras.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/assets/js/main.js
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No anadir librerias nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener la identidad visual actual.
|
||||
- Mantener el trabajo centrado en shell/layout.
|
||||
|
||||
## Validation
|
||||
- Hero, trailer y panel de servidores comparten el mismo ancho util en desktop.
|
||||
- La pagina se percibe mas unificada.
|
||||
- No quedan secciones visualmente demasiado estrechas respecto a otras.
|
||||
- El responsive sigue funcionando.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 180 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `frontend/index.html` introduce un `panel__shell` comun en trailer y servidores para que ambas secciones compartan el mismo carril interior.
|
||||
- `frontend/assets/css/styles.css` reemplaza los anchos independientes de hero, trailer y servidores por un sistema unificado con `--page-shell-width` y `--panel-content-width`.
|
||||
- El ajuste se mantuvo centrado en layout, paddings y separacion vertical, sin redisenar el contenido.
|
||||
|
||||
## Validation Result
|
||||
- Revisado en diff: la task queda limitada a `frontend/index.html`, `frontend/assets/css/styles.css` y el archivo de task, dentro del scope esperado.
|
||||
- Revisado en codigo: hero, trailer y panel de servidores pasan a compartir un mismo ancho maestro en desktop y un mismo carril interior para el contenido principal.
|
||||
- El responsive existente se conserva con los breakpoints moviles previos y con padding especifico para paneles en `max-width: 640px`.
|
||||
|
||||
## Decision Notes
|
||||
- Se unifico el sistema de shell a nivel de seccion y de carril interior en lugar de tocar el contenido de cada bloque, para cumplir el objetivo visual sin abrir un rediseno mayor.
|
||||
@@ -0,0 +1,59 @@
|
||||
# TASK-044-remove-test-signals-and-technical-summary-strips
|
||||
|
||||
## Goal
|
||||
Eliminar de la interfaz principal los elementos, etiquetas y resumenes que den sensacion de entorno de pruebas o validacion tecnica, dejando una experiencia mas limpia y orientada a producto final.
|
||||
|
||||
## Context
|
||||
La pagina ya esta entrando en una fase mas cercana a producto final. Sin embargo, siguen apareciendo elementos como "captura real reciente", resumenes tecnicos o textos que funcionan bien para desarrollo, pero no para una experiencia publica mas madura.
|
||||
|
||||
## Steps
|
||||
1. Revisar el bloque actual de servidores y los elementos intermedios previos a la rejilla de tarjetas.
|
||||
2. Eliminar o simplificar los elementos que indiquen:
|
||||
- validacion interna
|
||||
- estado de prueba
|
||||
- resumenes tecnicos poco utiles para el visitante
|
||||
3. Quitar la seccion visual equivalente a "captura real reciente".
|
||||
4. Quitar la fila o bloque de resumen tipo "vista previa historica" si no aporta valor claro al usuario final.
|
||||
5. Mantener solo el copy que ayuda a entender el bloque como producto real.
|
||||
6. Asegurar que el panel de servidores quede mas limpio y mas directo.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No romper el consumo de datos reales.
|
||||
- No eliminar fallbacks internos, solo su exposicion innecesaria en la UI.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el ajuste centrado en limpieza de producto.
|
||||
|
||||
## Validation
|
||||
- Desaparecen indicios de "modo prueba" en la vista principal.
|
||||
- El bloque de servidores se percibe mas limpio y mas orientado a usuario final.
|
||||
- La pagina mantiene funcionalidad completa.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 140 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `frontend/index.html` elimina el bloque visual de fuente/estado y la franja de resumen historico previa a la rejilla.
|
||||
- `frontend/assets/js/main.js` mantiene la logica interna de estados, pero reduce la exposicion publica a un badge limpio y copy orientado a producto.
|
||||
- `frontend/assets/css/styles.css` retira los estilos de los strips tecnicos eliminados.
|
||||
|
||||
## Validation Result
|
||||
- Revisado en codigo: los datos reales siguen hidratando el panel y la diferenciacion interna entre live, historical y fallback se conserva en JavaScript.
|
||||
- Validado con `node --check frontend/assets/js/main.js`.
|
||||
- Revisado en diff: la task queda limitada a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y el archivo de task.
|
||||
|
||||
## Decision Notes
|
||||
- La limpieza se resolvio ocultando por completo los bloques tecnicos y simplificando el lenguaje de estado, en lugar de introducir nuevas superficies UI intermedias.
|
||||
@@ -0,0 +1,69 @@
|
||||
# TASK-045-simplify-real-server-cards-for-product-ui
|
||||
|
||||
## Goal
|
||||
Simplificar las tarjetas de servidores reales para mostrar solo la informacion mas util para el visitante final, mejorando la claridad y reduciendo ruido visual y tecnico.
|
||||
|
||||
## Context
|
||||
Las tarjetas actuales ya muestran datos reales A2S, pero siguen ensenando informacion que no aporta suficiente valor para la experiencia principal. La tarjeta debe centrarse en lo esencial: nombre, estado, jugadores, mapa, region, ultima captura y CTA de conexion. Cualquier metrica adicional debe ser secundaria o eliminarse si no mejora claramente la lectura.
|
||||
|
||||
## Steps
|
||||
1. Revisar la estructura actual de las tarjetas reales.
|
||||
2. Reducir la informacion visible principal a:
|
||||
- nombre
|
||||
- estado
|
||||
- jugadores actuales
|
||||
- mapa
|
||||
- region
|
||||
- ultima captura
|
||||
- boton Conectar
|
||||
3. Evaluar si promedio y pico deben quedar como datos secundarios discretos o desaparecer.
|
||||
4. Eliminar de la tarjeta elementos como:
|
||||
- tendencia reciente
|
||||
- numero de capturas
|
||||
- bloques densos poco utiles
|
||||
5. Reorganizar la tarjeta para que se lea rapido y con claridad.
|
||||
6. Mantener una composicion limpia y coherente con el diseno actual.
|
||||
7. Asegurar buena legibilidad en desktop y movil.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
- backend/app/payloads.py
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No tocar backend salvo alineacion menor si fuera imprescindible.
|
||||
- No romper la CTA Conectar.
|
||||
- No anadir librerias nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el ajuste centrado en UX de producto final.
|
||||
|
||||
## Validation
|
||||
- Las tarjetas reales muestran solo la informacion mas util y legible.
|
||||
- Desaparece ruido tecnico innecesario.
|
||||
- La CTA Conectar sigue visible y clara.
|
||||
- La UI gana sensacion de producto final.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 160 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `frontend/assets/js/main.js` simplifica el render de tarjetas reales a identidad, estado, poblacion, quick facts y CTA, eliminando resumen historico, tendencia y llamadas auxiliares ya innecesarias.
|
||||
- `frontend/assets/css/styles.css` elimina estilos asociados a bloques tecnicos densos y deja una composicion mas directa para las quick facts.
|
||||
- No fue necesario tocar backend ni cambiar la CTA `Conectar`.
|
||||
|
||||
## Validation Result
|
||||
- Validado con `node --check frontend/assets/js/main.js`.
|
||||
- Revisado en codigo: las tarjetas mantienen nombre, estado, jugadores, mapa, region, ultima captura y CTA, y desaparecen tendencia, capturas, promedio y pico.
|
||||
- Revisado en diff: la task queda limitada a `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y el archivo de task.
|
||||
|
||||
## Decision Notes
|
||||
- Se opto por eliminar por completo las metricas secundarias en lugar de rebajarlas visualmente, porque seguian cargando la tarjeta y no aportaban suficiente valor a la lectura principal.
|
||||
44
ai/tasks/done/TASK-046-near-full-width-master-shell.md
Normal file
44
ai/tasks/done/TASK-046-near-full-width-master-shell.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# TASK-046-near-full-width-master-shell
|
||||
|
||||
## Goal
|
||||
Sustituir la columna central demasiado estrecha por un shell maestro mucho más ancho, de forma que la landing use casi todo el ancho útil de desktop y reduzca drásticamente el espacio vacío lateral.
|
||||
|
||||
## Context
|
||||
La UI ya unificó las secciones bajo un mismo sistema de anchura, pero ese sistema sigue siendo demasiado estrecho. El resultado es una página encajada en el centro con mucho espacio muerto a izquierda y derecha. El objetivo de esta task es ampliar el carril principal de la landing hasta un ancho cercano al total útil de la ventana, manteniendo márgenes razonables.
|
||||
|
||||
## Steps
|
||||
1. Revisar el shell principal actual y cualquier `max-width` asociado.
|
||||
2. Sustituir el ancho maestro actual por uno claramente más amplio en desktop.
|
||||
3. Usar una referencia tipo:
|
||||
- `width: min(1600px, calc(100vw - 64px))`
|
||||
o equivalente coherente con el diseño actual.
|
||||
4. Mantener márgenes laterales razonables sin dejar la web pegada a los bordes.
|
||||
5. Asegurar que el comportamiento responsive en tablet y móvil siga siendo correcto.
|
||||
6. No rediseñar contenidos; solo ampliar el carril principal de la landing.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/index.html si fuera necesario alinear wrappers
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No añadir librerías nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener la identidad visual actual.
|
||||
- Mantener el trabajo centrado en el shell principal.
|
||||
|
||||
## Validation
|
||||
- La página usa mucho mejor el ancho disponible en desktop.
|
||||
- Disminuye claramente el espacio vacío lateral.
|
||||
- Hero, tráiler y servidores siguen alineados en un mismo carril visual.
|
||||
- Tablet y móvil no se rompen.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 2 archivos modificados.
|
||||
- Preferir menos de 120 líneas cambiadas.
|
||||
44
ai/tasks/done/TASK-047-remove-nested-width-constraints.md
Normal file
44
ai/tasks/done/TASK-047-remove-nested-width-constraints.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# TASK-047-remove-nested-width-constraints
|
||||
|
||||
## Goal
|
||||
Eliminar o corregir restricciones internas de anchura que siguen estrechando hero, tráiler y panel de servidores aunque el shell principal se haya ensanchado.
|
||||
|
||||
## Context
|
||||
En la UI actual hay indicios claros de que, además del shell principal, existen wrappers interiores o `max-width` secundarios que mantienen las secciones demasiado estrechas. Esta task debe identificar y eliminar esas restricciones internas para que cada sección ocupe realmente el ancho disponible del carril principal.
|
||||
|
||||
## Steps
|
||||
1. Revisar la estructura HTML y CSS de hero, tráiler y panel de servidores.
|
||||
2. Identificar wrappers internos con `max-width`, anchuras fijas o márgenes automáticos que estrechen el contenido.
|
||||
3. Corregir esas restricciones para que:
|
||||
- hero
|
||||
- tráiler
|
||||
- panel de servidores
|
||||
usen `width: 100%` dentro del shell principal.
|
||||
4. Mantener una composición limpia y centrada, sin volver a una columna estrecha.
|
||||
5. Evitar que un wrapper interno rompa el ancho unificado buscado.
|
||||
6. No rediseñar secciones; solo liberar el ancho real utilizable.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No añadir librerías nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener la estructura visual existente salvo correcciones de anchura.
|
||||
|
||||
## Validation
|
||||
- No quedan wrappers interiores que vuelvan a estrechar las secciones principales.
|
||||
- Hero, tráiler y servidores ocupan realmente el ancho del shell maestro.
|
||||
- La sensación de “columna central demasiado angosta” desaparece o se reduce claramente.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 2 archivos modificados.
|
||||
- Preferir menos de 120 líneas cambiadas.
|
||||
43
ai/tasks/done/TASK-048-wide-desktop-server-grid-pass.md
Normal file
43
ai/tasks/done/TASK-048-wide-desktop-server-grid-pass.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# TASK-048-wide-desktop-server-grid-pass
|
||||
|
||||
## Goal
|
||||
Aprovechar el nuevo ancho de desktop para que el panel de servidores use una rejilla más amplia y cómoda, evitando que las tarjetas sigan viéndose pequeñas o demasiado encerradas.
|
||||
|
||||
## Context
|
||||
Una vez ampliado el shell principal y eliminadas restricciones internas, el panel de servidores debe beneficiarse directamente de ese ancho. Si la rejilla sigue siendo demasiado conservadora, la página seguirá dando sensación de estrechez aunque el contenedor ya sea ancho.
|
||||
|
||||
## Steps
|
||||
1. Revisar la rejilla actual del panel de servidores.
|
||||
2. Ajustar el grid para que aproveche mejor desktop ancho.
|
||||
3. Usar una estrategia robusta tipo:
|
||||
- `repeat(auto-fit, minmax(360px, 1fr))`
|
||||
o equivalente mejor adaptada al diseño actual.
|
||||
4. Revisar gaps, paddings y anchuras mínimas para evitar tarjetas pequeñas o apretadas.
|
||||
5. Mantener buen comportamiento en tablet y móvil.
|
||||
6. No rediseñar la tarjeta; centrarse en cómo la rejilla usa el ancho disponible.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/index.html
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/assets/css/styles.css
|
||||
- frontend/index.html si hiciera falta alinear clases o wrappers
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No añadir librerías nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el trabajo centrado en grid y aprovechamiento del ancho.
|
||||
|
||||
## Validation
|
||||
- El panel de servidores se ve más amplio y mejor repartido en desktop.
|
||||
- Las tarjetas dejan de sentirse pequeñas o encajadas.
|
||||
- La UI mantiene buena lectura en tablet y móvil.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 2 archivos modificados.
|
||||
- Preferir menos de 120 líneas cambiadas.
|
||||
@@ -0,0 +1,62 @@
|
||||
# TASK-049-remove-nonessential-copy-and-technical-badges
|
||||
|
||||
## Goal
|
||||
Eliminar de la landing los textos descriptivos y etiquetas tecnicas que no aportan valor al usuario final, dejando una interfaz mas limpia, directa y orientada a producto final.
|
||||
|
||||
## Context
|
||||
La UI ya esta en una fase suficientemente madura como para prescindir de copy de presentacion y de labels internos o tecnicos. Actualmente siguen apareciendo textos de relleno o de tono demasiado explicativo, asi como etiquetas como "Snapshot real A2S", que no deberian estar visibles en la vista principal publica.
|
||||
|
||||
## Steps
|
||||
1. Revisar el hero, bloque de trailer y bloque de servidores.
|
||||
2. Eliminar o simplificar textos descriptivos no esenciales, incluyendo ejemplos como:
|
||||
- descripciones explicativas del trailer
|
||||
- copy redundante del bloque de servidores
|
||||
- textos internos de validacion o sistema
|
||||
3. Eliminar de las tarjetas reales etiquetas tecnicas como:
|
||||
- "Snapshot real A2S"
|
||||
4. Revisar tambien chips o badges secundarios que aporten poco valor al usuario final.
|
||||
5. Mantener solo el texto minimo necesario para entender cada seccion.
|
||||
6. Preservar claridad y estetica sin dejar la pagina vacia ni fria.
|
||||
7. No tocar backend en esta task.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No tocar backend.
|
||||
- No eliminar informacion util de servidor como mapa, jugadores, region, estado, ultima actualizacion y CTA.
|
||||
- No anadir librerias nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el ajuste centrado en copy/UI.
|
||||
|
||||
## Validation
|
||||
- Desaparecen textos descriptivos innecesarios.
|
||||
- Desaparecen etiquetas tecnicas como "Snapshot real A2S".
|
||||
- La pagina se percibe mas limpia y mas finalista.
|
||||
- La informacion util del servidor sigue intacta.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 120 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `frontend/index.html` elimina copy descriptivo del hero y del bloque de trailer, simplifica el encabezado de servidores y quita etiquetas secundarias en las tarjetas estaticas.
|
||||
- `frontend/assets/js/main.js` sustituye textos tecnicos por textos de producto mas directos y elimina labels internos visibles en tarjetas y estados del bloque de servidores.
|
||||
- `frontend/assets/css/styles.css` elimina el estilo del texto descriptivo del hero ya retirado del markup.
|
||||
|
||||
## Validation Result
|
||||
- Validado con `node --check frontend/assets/js/main.js`.
|
||||
- Verificado con `rg` que ya no quedan labels visibles como `Snapshot real A2S`, `Fallback estatico`, `Servidor de referencia` o equivalentes en `frontend/`.
|
||||
- Revisado en diff: la task queda limitada a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y este archivo de task. El cambio no toca backend.
|
||||
|
||||
## Decision Notes
|
||||
- Se mantuvo una nota breve en el bloque de servidores para no dejar la seccion fria, pero se reescribio a una forma claramente orientada a usuario final y sin lenguaje interno del sistema.
|
||||
@@ -0,0 +1,67 @@
|
||||
# TASK-050-live-snapshot-refresh-and-frontend-polling-alignment
|
||||
|
||||
## Goal
|
||||
Alinear la captura periodica de snapshots y el consumo del frontend para que la web muestre datos mucho mas cercanos al estado real actual de los servidores, evitando que se queden estancados durante horas.
|
||||
|
||||
## Context
|
||||
La pagina ya consume datos reales A2S, pero en la practica estaba mostrando snapshots demasiado antiguos, con mapas y poblacion desactualizados. Esto degrada la percepcion de fiabilidad del producto. El sistema necesitaba una politica mas util de refresco local y una lectura periodica razonable desde frontend.
|
||||
|
||||
## Steps
|
||||
1. Revisar como se ejecuta actualmente el scheduler local de snapshots.
|
||||
2. Revisar la frecuencia de captura actual o la ausencia de ejecucion continua.
|
||||
3. Definir una frecuencia de refresco razonable para entorno local de desarrollo y demo, por ejemplo:
|
||||
- captura backend cada 60 segundos
|
||||
- refresco frontend cada 60-90 segundos
|
||||
4. Ajustar el scheduler o su configuracion para facilitar un refresco frecuente y controlado.
|
||||
5. Revisar el frontend para que vuelva a consultar el backend periodicamente sin necesidad de recargar la pagina.
|
||||
6. Asegurar que el refresco no rompa la UI ni genere comportamiento agresivo.
|
||||
7. Mantener el sistema simple y apropiado para la fase actual.
|
||||
8. Documentar claramente como arrancar el backend y el refresco para ver datos vivos.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- backend/README.md
|
||||
- backend/app/config.py
|
||||
- backend/app/scheduler.py
|
||||
- backend/app/collector.py
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/index.html
|
||||
|
||||
## Expected Files to Modify
|
||||
- backend/README.md
|
||||
- backend/app/config.py
|
||||
- backend/app/scheduler.py
|
||||
- frontend/assets/js/main.js
|
||||
- opcionalmente frontend/index.html si requiere una alineacion minima
|
||||
|
||||
## Constraints
|
||||
- No introducir infraestructura pesada.
|
||||
- No anadir librerias nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- No abrir nuevas fuentes de datos.
|
||||
- Mantener la solucion simple, local y util para producto actual.
|
||||
|
||||
## Validation
|
||||
- El sistema puede refrescar snapshots reales con una frecuencia razonable.
|
||||
- El frontend actualiza la vista sin depender de recarga manual.
|
||||
- Los mapas y jugadores cambian cuando cambian realmente en los servidores.
|
||||
- La documentacion deja claro como usar este flujo en local.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 5 archivos modificados.
|
||||
- Preferir menos de 180 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `backend/app/config.py` baja el intervalo por defecto del scheduler local a `60` segundos para acercar la persistencia a una demo viva.
|
||||
- `backend/app/scheduler.py` alinea la ayuda del comando con ese nuevo comportamiento orientado a desarrollo y demo.
|
||||
- `frontend/index.html` expone `data-server-refresh-ms=\"60000\"` y `frontend/assets/js/main.js` reutiliza ese valor para relanzar `hydrateServers()` cada `60` segundos sin recargar la pagina y sin solapar peticiones.
|
||||
- `backend/README.md` documenta el flujo local recomendado con backend, scheduler y polling del frontend.
|
||||
|
||||
## Validation Result
|
||||
- Validado con `node --check frontend/assets/js/main.js`.
|
||||
- Validado con `python -m py_compile backend/app/config.py backend/app/scheduler.py backend/app/collector.py`.
|
||||
- Revisado en diff: la task queda limitada a `backend/README.md`, `backend/app/config.py`, `backend/app/scheduler.py`, `frontend/assets/js/main.js`, `frontend/index.html` y este archivo de task.
|
||||
|
||||
## Decision Notes
|
||||
- Se mantuvo el polling solo sobre el bloque de servidores para no convertir toda la landing en una pagina con refresco agresivo. Salud del backend y trailer siguen siendo una hidratacion inicial simple.
|
||||
@@ -0,0 +1,66 @@
|
||||
# TASK-051-real-server-card-minimal-product-pass
|
||||
|
||||
## Goal
|
||||
Dejar las tarjetas de servidores reales en una forma minima y orientada a producto final, mostrando solo la informacion esencial para un visitante que quiere ver estado actual y conectarse.
|
||||
|
||||
## Context
|
||||
Las tarjetas ya se simplificaron parcialmente, pero todavia quedaban restos de estructura y bloques secundarios que no aportaban suficiente valor. El objetivo era dejar una tarjeta muy clara y minima, centrada en estado actual del servidor.
|
||||
|
||||
## Steps
|
||||
1. Revisar la composicion actual de las tarjetas reales.
|
||||
2. Asegurar que el contenido visible principal quede limitado a:
|
||||
- nombre
|
||||
- estado
|
||||
- jugadores
|
||||
- mapa
|
||||
- region
|
||||
- ultima actualizacion
|
||||
- boton Conectar
|
||||
3. Evaluar si promedio y pico deben quedar ocultos o pasar a una capa secundaria muy discreta.
|
||||
4. Eliminar cualquier bloque residual que complique la lectura rapida.
|
||||
5. Mejorar la jerarquia para que el usuario vea en pocos segundos si el servidor le interesa.
|
||||
6. Mantener una composicion limpia y coherente con el ancho actual de la pagina.
|
||||
7. No tocar backend salvo una alineacion menor si fuera imprescindible.
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
- backend/app/payloads.py
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/index.html
|
||||
- frontend/assets/js/main.js
|
||||
- frontend/assets/css/styles.css
|
||||
|
||||
## Constraints
|
||||
- No romper el boton Conectar.
|
||||
- No eliminar la informacion util esencial.
|
||||
- No anadir librerias nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el ajuste centrado en UX de producto final.
|
||||
|
||||
## Validation
|
||||
- Las tarjetas muestran solo informacion util y clara.
|
||||
- La lectura es rapida y limpia.
|
||||
- No quedan bloques residuales de informacion interna o excesiva.
|
||||
- La UI se siente mas final y menos experimental.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados.
|
||||
- Preferir menos de 140 lineas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- `frontend/assets/js/main.js` deja las tarjetas dinamicas en su forma minima: identidad, estado, jugadores, mapa, region, ultima actualizacion y CTA cuando existe destino conectable.
|
||||
- `frontend/index.html` alinea las tarjetas estaticas de fallback con esa misma estructura minima.
|
||||
- `frontend/assets/css/styles.css` elimina estilos de bloques residuales ya innecesarios, como la barra de carga y los encabezados intermedios de seccion, para reforzar una lectura mas rapida.
|
||||
|
||||
## Validation Result
|
||||
- Validado con `node --check frontend/assets/js/main.js`.
|
||||
- Verificado con `rg` que ya no quedan restos de `server-card__load`, `server-panel-section`, ni texto asociado a metricas o bloques historicos secundarios dentro de `frontend/`.
|
||||
- Revisado en diff: la task queda limitada a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y este archivo de task.
|
||||
|
||||
## Decision Notes
|
||||
- Se elimino la barra visual de ocupacion porque duplicaba la informacion ya expresada por `Jugadores` y cargaba la tarjeta sin mejorar la decision principal del visitante.
|
||||
@@ -1 +1 @@
|
||||
39568
|
||||
32960
|
||||
Reference in New Issue
Block a user