[🛠] Enrutamiento por versiones del registro corporal sin romper Daily Reviews anteriores

✨ Resumen de GPT-5.6 Sol 　

El registro de cómo descubrí que seguir cambiando la interfaz corporal podía hacer incompatibles las entradas antiguas con la estructura más reciente, y vinculé renderer, schema y validator a una misma versión mediante un único schema_version.

body_review tenía una versión, pero el renderer no la usaba

Después de crear un MVP de dieta y registro de comidas dentro del blog, separé Hoy y Últimos 7 días en la vista contraída e impedí que las tarjetas expandidas se rompieran en espacios estrechos. También cambié las estrellas blancas de los veredictos de coaching para que usaran la misma puntuación que el registro corporal.

Mientras seguía modificando la pantalla apareció un problema mayor. El front matter ya incluía schema_version, pero _includes/body-review.html ignoraba ese valor y renderizaba directamente la estructura más reciente. Si la estructura de datos cambiaba más adelante, los Daily Reviews antiguos podían entrar en el renderer nuevo y romperse.

Ir directamente al renderer vN desde schema_version

No llené body-review.html con una lista creciente de case when para cada versión. La ruta se construye con el número y el archivo correspondiente se incluye de forma directa.

{%- assign schema_version = review.schema_version | plus: 0 -%}
{%- capture renderer_path -%}body-review/v{{ schema_version }}.html{%- endcapture -%}
{% include {{ renderer_path }} review=review %}

v4 va a body-review/v4.html y v100 va a body-review/v100.html. Tampoco hay un límite superior que bloquee de pronto v101. Si el archivo de esa versión existe, la misma regla lo conecta; si no existe, el build falla en lugar de usar silenciosamente la versión más reciente como fallback.

Mantener renderer, schema y validator con el mismo número

Versionar solo la pantalla todavía podía hacer que la validación de entrada se desviara. Por eso cada versión quedó formada por tres archivos.

_includes/body-review/v4.html
_project/blog-system/body-review-schemas/v4.yml
_project/blog-system/body-review-validators/v4.rb

El verificador encuentra todos los vN del repository y falla si falta cualquiera de los tres archivos o si el renderer no contiene su marcador body-review--vN. Solo se añade una versión cuando la estructura de datos debe cambiar, mientras que una entrada ya publicada continúa interpretándose con la versión que declara.

También aproveché v4 para corregir los problemas visibles que me molestaban. El resumen contraído coloca Hoy y Últimos 7 días en filas separadas, y las tarjetas expandidas pasan de tres columnas a dos y después a una según el ancho del propio component. El registro corporal y los veredictos de coaching usan el mismo include de puntuación, mientras que los textos de la UI y los labels de accesibilidad provienen de los data de cada idioma activo.

Los cambios simples de texto o style pueden quedarse ahora dentro de v4. Si un cambio rompe el data shape, se añade un nuevo conjunto vN. Crear una pantalla nueva ya no exige reescribir al mismo tiempo todas las entradas antiguas.