Promote rcon historical model to primary

ai/tasks/done/TASK-104-landing-loading-state-and-stale-lock-hardening.md

@@ -0,0 +1,45 @@
+# TASK-104-landing-loading-state-and-stale-lock-hardening
+
+## Goal
+Corregir dos problemas de producto/operación ya detectados:
+1. la landing muestra primero datos fake estáticos antes de hidratar
+2. los stale locks entre contenedores Docker siguen bloqueando pasadas manuales aunque los workers ya estén parados
+
+## Context
+Se ha confirmado que:
+- la homepage renderiza cards estáticas fake y luego las sustituye al hidratar
+- eso genera un flash de datos falsos
+- además, el lock compartido puede quedar huérfano entre contenedores y requiere borrado manual
+
+## Steps
+1. Para la landing:
+   - auditar `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css`
+   - aplicar la opción A:
+     - no mostrar cards fake iniciales
+     - dejar contenedor vacío o skeleton/loading state
+     - renderizar solo datos reales al hidratar
+     - degradar limpio si falla la API
+2. Para el stale lock:
+   - auditar `backend/app/writer_lock.py`
+   - mejorar la detección/recuperación de locks huérfanos entre contenedores Docker
+   - no depender únicamente del hostname si eso bloquea recuperación válida
+   - mantener seguridad para no liberar locks activos por error
+3. Documentar el comportamiento actualizado en README/runbook.
+
+## Constraints
+- No rehacer la landing completa.
+- No romper el single-writer lock.
+- No volver al comportamiento sin coordinación.
+- No introducir riesgo de liberar locks válidos sin comprobación suficiente.
+
+## Validation
+- La landing ya no muestra datos fake antes de hidratar.
+- Los locks huérfanos entre contenedores se recuperan mejor o quedan claramente resueltos.
+- La repo queda consistente.
+
+## Expected Files
+- `frontend/index.html`
+- `frontend/assets/js/main.js`
+- `frontend/assets/css/styles.css`
+- `backend/app/writer_lock.py`
+- `backend/README.md`