El caso Pruebas 03 6 min de lectura

Hicimos un fork para reutilizar el motor. Heredamos el producto equivocado.

Una prueba con HabitaLocal y Repueblo sobre la diferencia entre reutilizar infraestructura y reutilizar criterio.

Una casa de arcilla con la llave antigua de otra puerta atada al tejado.
Una casa de arcilla con la llave antigua de otra puerta atada al tejado.

Repueblo nació copiando HabitaLocal.

No es una metáfora. Es un fork.

HabitaLocal intenta responder si un local comercial podría convertirse en vivienda y si merece la pena estudiar la operación. Repueblo intenta responder si merece la pena mudarse y rehabilitar una casa en un municipio rural. Los dos necesitan fuentes oficiales, un índice, páginas por territorio, informes y una forma honesta de representar incertidumbre.

Parecía una prueba perfecta de una idea que defiendo: si separamos las reglas del resultado, el siguiente producto debería costar menos.

La infraestructura se reutilizó.

También se reutilizaron 225 menciones al producto anterior dentro de 60 archivos del código de aplicación y sus scripts.

El fork había copiado el motor. Y, pegado a él, había copiado una parte de la identidad, del problema y de las promesas de HabitaLocal.

Lo que sí era reutilizable

El propio documento de pivote de Repueblo hace una distinción bastante limpia.

Se pueden conservar casi tal cual:

  • la estructura del sitio;
  • autenticación y captación de leads;
  • la infraestructura de pagos;
  • el patrón de recolectar, normalizar y archivar datos con fecha y hash;
  • el generador de informes;
  • base de datos, observabilidad y despliegue.

Son capacidades. No contienen por sí mismas una respuesta sobre dónde vivir.

También hay partes que deben cambiar de significado:

  • una zona urbana pasa a ser un municipio rural;
  • los cinco factores de cambio de uso pasan a seis factores de habitabilidad rural;
  • normativa urbanística pasa a ayudas, demografía, servicios, conectividad y distancia;
  • una ficha de local pasa a ser una ficha de pueblo.

Y hay una tercera categoría que hay que tirar o desactivar: calculadoras de obra de un local, reglas sobre planta baja, ejes comerciales y normativa específica de cambio de uso.

El mapa estaba bien escrito.

El código todavía no había terminado de obedecerlo.

La contaminación no estaba escondida

Al buscar habitalocal, local comercial y sus variantes dentro de src/ y scripts/ de Repueblo aparecieron 225 coincidencias en 60 archivos.

No todas son errores. Algunas son comentarios históricos, compatibilidad temporal o referencias deliberadas al origen. Contarlas no demuestra por sí solo que haya 225 fallos.

Pero varias sí cruzan la frontera del producto:

  • títulos de página que todavía dicen HabitaLocal;
  • un correo de contacto del producto anterior;
  • metadatos y sitemap con el dominio anterior;
  • páginas completas sobre cambio de uso;
  • textos legales que describen otra actividad;
  • scripts de imágenes que todavía piden un local con persiana metálica;
  • una configuración de despliegue que el propio documento marca como “no desplegar”.

Esto es exactamente lo que debería ocurrir en un fork recién iniciado. El repositorio no lo oculta: su README dice que está recién copiado, enumera lo que falta y advierte que no se despliegue.

La prueba no denuncia un proyecto inacabado. Usa ese estado para mostrar una frontera que solemos dibujar mal.

Diagrama: de HabitaLocal, solo la infraestructura debería llegar a Repueblo; el criterio del dominio y la marca no deberían cruzar.

Reutilizar código no es reutilizar un sistema

Un sistema reusable no es el que puede copiarse. Cualquier carpeta puede copiarse.

Es el que hace explícito qué puede viajar y qué debe quedarse atrás.

En este caso, el patrón fetch → normalize → archive puede viajar porque no decide qué es una buena vivienda ni qué pueblo merece atención. En cambio, una fórmula de viabilidad, una advertencia legal o la definición de “zona” contienen criterio del dominio.

Podemos describir la separación con cuatro capas:

Capa Pregunta ¿Puede viajar?
Fontanería ¿Cómo autenticamos, cobramos, almacenamos y publicamos? Normalmente sí
Evidencia ¿Cómo guardamos fuente, fecha, licencia y confianza? Sí, si el contrato es neutro
Decisión ¿Qué factores importan y cómo se ponderan? Solo si el problema es equivalente
Promesa ¿Qué cree el usuario que estamos resolviendo? No

El error típico consiste en llamar “motor” a la mezcla de las cuatro.

Entonces llega el segundo producto y descubrimos que el motor sabía demasiado sobre el primero.

Una prueba mejor que contar coincidencias

El recuento de palabras sirve como detector inicial, no como veredicto. La siguiente prueba debería definir un contrato de independencia entre dominios.

Antes de poder desplegar Repueblo:

  1. ninguna ruta pública puede mencionar la marca, el dominio o el correo de HabitaLocal;
  2. ninguna decisión del índice puede importar factores de cambio de uso;
  3. cada fuente oficial debe declarar qué señal rural respalda;
  4. los módulos compartidos no pueden usar sustantivos del dominio en sus interfaces;
  5. una muestra de municipios debe producir resultados sin cargar datos de locales;
  6. cualquier excepción histórica debe quedar marcada y justificada.

No basta con que una búsqueda dé cero. También hace falta una prueba positiva: demostrar que el nuevo índice funciona con señales nuevas.

El objetivo no es un repositorio limpio de palabras prohibidas. Es un producto incapaz de formular accidentalmente la promesa anterior.

“Pero eso es normal en cualquier fork”

Exacto.

Y por eso el fork es una buena prueba.

Las teorías sobre sistemas suelen enseñarse con arquitecturas terminadas. Todo está separado, las cajas tienen nombres perfectos y las flechas no arrastran historia. Un fork enseña la realidad: nombres antiguos, dependencias oportunistas, configuraciones mezcladas y decisiones que nunca supimos que pertenecían al dominio.

No invalida la reutilización. La hace medible.

Si Repueblo termina necesitando reescribir autenticación, archivo, pagos y publicación, la plataforma era menos reusable de lo que creíamos. Si puede conservar esas capas y reemplazar por completo criterio y promesa, tendremos evidencia de una separación real.

Hoy solo podemos afirmar la primera mitad: hay una intención explícita de separar y una cantidad concreta de residuo por retirar. Todavía no hay una prueba completa de independencia.

Lo que he aprendido

Pensaba que escribir reglas permitiría producir más resultados con el mismo sistema.

Ahora lo formularía así:

Un sistema reusable no conserva respuestas. Conserva la capacidad de construir respuestas nuevas sin arrastrar las anteriores.

HabitaLocal aporta una disciplina valiosa: fuente oficial, fecha de consulta, estimaciones marcadas y la posibilidad de responder verificar cuando falta un dato. Eso sí merece viajar.

La definición de viabilidad de un local no.

Repueblo no será la demostración de que podemos clonar productos. Será más interesante si demuestra que podemos separar infraestructura, evidencia, criterio y promesa sin engañarnos sobre el coste.

En el Instituto de Diseño Agéntico no usamos proyectos reales para decorar el método. Los usamos para encontrar estas costuras: el punto exacto donde una abstracción deja de ser cierta y obliga a escribir una regla mejor.


Nota de verificación editorial

Revisión realizada el 14 de septiembre de 2026 sobre Repueblo, revisión 1dc2ff8. El recuento se limitó a src/ y scripts/, excluyendo dependencias y artefactos de compilación: 225 coincidencias en 60 archivos para habitalocal, local comercial y locales comerciales, sin clasificar automáticamente cada aparición como defecto. El README y docs/PIVOT-REPUEBLO.md declaran que el fork está sin terminar y que no debe desplegarse todavía.

Fuentes

#pruebas#habitalocal#repueblo#reutilización

A seguir

Redactado con ayuda de IA, contrastado contra su fuente y firmado por Joan Arbó.