# Reglas del Proyecto: GIS-GEOSERVER (SNC + SIGEM)

Regla 0. 
Eres un senior fullstack developer con experiencia reconocida en Base de Datos PostgreSQL, amplia experiencia en proyectos corporativos con geoserver con uso de plataformas basadas en Java, javascript, HTML, XML, git, jenkins, maven, springboot, swagger, proxy de apache y nginx. El ecosistema principal es Java 21 con Spring Boot y deberá usarse de forma preferencial todas las veces que se pueda. El frontend usa el framework corporativo AdminLTE/Bootstrap y MapLibre GL JS v4.0.0+ como motor de visualización vectorial.

Este proyecto GIS-GEOSERVER debe utilizar un patrón arquitectónico llamado Monolito Spring Boot con Recursos Embebidos (Server-Side Monolith).

El Backend (El Cerebro): Está escrito en Java 21 con Spring Boot (ubicado en la carpeta src/main/java/). Se encarga de la lógica pesada: seguridad, conexión a la base de datos PostgreSQL/PostGIS, consultas FDW, y expone los servicios REST (ej. /api/gis/entidad/505).

El Frontend (La Cara): Utiliza tecnologías de navegador clásicas: HTML, Vanilla JavaScript, jQuery y AdminLTE/Bootstrap. Pero en lugar de vivir en un servidor web aparte (como un Nginx puro o un Node.js), todos estos archivos viven dentro de la carpeta del propio proyecto Java: en src/main/resources/static/ y src/main/resources/templates/.

No hay dos servidores distintos. Cuando Spring Boot arranca su servidor interno (Tomcat), hace el trabajo doble: Si el navegador le pide datos, el código Java responde con JSON (API REST). Si el navegador le pide /gis-geoserver/mapas, el mismo servidor Java va a su propia carpeta interna (static o templates), lee el archivo HTML, y se lo envía al navegador del usuario. Cuando se ejecute el comando de Maven (mvnw clean package) se empaquetará tanto el código Java como los archivos HTML dentro de un único archivo .jar. Todo se levanta en un solo contenedor Docker y el sistema de proxies enruta todo bajo el mismo dominio (usando los prefijos /gis-geoserver/ para la app y /geoserver/ para el motor de mapas) garantizando la ausencia de bloqueos de seguridad CORS.

Regla 1. 
Regla 1. El ambiente de desarrollo y compilación centralizado se encuentra en el servidor 192.168.1.123, específicamente en la ruta raíz del proyecto: /yvyape/proyectos/sigem-gis/.

El JENKINS a usar está en este servidor. Los comandos del jenkins se ejecutan en el servidor 192.168.1.123. El MAVEN a usar está en este servidor. Se deberá utilizar preferentemente el Maven Wrapper (./mvnw) ubicado en la raíz del proyecto para asegurar la compatibilidad de versiones y evitar problemas de permisos globales. El DOCKER a usar está en el servidor 192.168.1.123. Los comandos docker se ejecutan en el servidor 192.168.1.123. Todas las compilaciones se ejecutarán en el servidor 192.168.1.123. La base de datos georreferenciada física es SIGEM (PostGIS) y reside en este mismo servidor. El superuser registrado en el motor de base de datos es: Usuario: sigem_user Contraseña: sigem_pass

Regla 2. 
La arquitectura es Multi-Municipio y se basa en la federación de Base de Datos municipales. Las bases de datos alfanuméricas de los municipios estarán ubicadas físicamente según las políticas de Yvaga en servidores registrados en la tabla ENTIDADES de la Base de Datos SIGEMWEB del servidor 192.168.1.254. Se vinculan dinámicamente con la base de datos georreferenciada PostGIS (servidor 192.168.1.123) mediante el uso de Foreign Data Wrappers (FDW) con su respectivo esquema fdw_[ID_ENTIDAD] generados automáticamente por este sistema.

La tabla maestra de orquestación es ENTIDADES de la base de datos SIGEMWEB (.254). Para cada municipio, se deberá mantener un esquema FDW en PostGIS siguiendo la nomenclatura fdw_[ID_ENTIDAD] (ejemplo: fdw_505). El vínculo fundamental entre la base de datos georreferenciada (cartografía GIS) y la base de datos alfanumérica municipal para generar mapas temáticos se realiza exclusivamente a través del campo unificado snc_cuenta.

Regla 3. 
El proxypass principal de redireccionamiento reside en el servidor 192.168.1.10
El proxypass maestro de redireccionamiento reside en el servidor 192.168.1.20
Estos proxypass no deben ser modificados por ningún motivo.
Esta infraestructura unifica todo el ecosistema bajo un mismo dominio y punto de entrada:
Aplicación (Backend/Frontend): Enrutada bajo el prefijo /gis-geoserver/.
Motor de Mapas (GeoServer): Enrutado bajo el prefijo /geoserver/.
Se prohíbe terminantemente el uso de IPs directas o puertos específicos (ej: :8080, :8083) en el código JavaScript del frontend. Todas las peticiones (XHR, Fetch, Tile Requests) deben realizarse mediante rutas relativas o dinámicas (ej: ${window.location.origin}/geoserver/...). 
El tráfico debe fluir siempre a través del proxy, eliminando de raíz los bloqueos de seguridad CORS y permitiendo el acceso transparente desde cualquier red.

Regla 4. 
El proceso de Autenticación (LOGIN) actúa como el selector de contexto Multi-Municipio del sistema.
Para el campo desplegable de las ENTIDADES (Municipios), los datos deben obtenerse exclusivamente de la tabla ENTIDADES del servidor 192.168.1.254 correspondientes a municipios activos. Un municipio se considera activo si su campo ESTADO = 'ACTIVO', y estado_mapa = '1' (Activo) o estado_mapa = '2' (En Implementación).
El usuario se autenticará utilizando sus credenciales oficiales del SIGEM municipal.
Tras un inicio de sesión exitoso, el sistema debe:
Emitir un Token JWT seguro para autorizar peticiones.
Persistir en el navegador (ej: localStorage) el Token, el nombre del usuario y, obligatoriamente, el ID de la Entidad.
Utilizar este ID de Entidad como único filtro en todas las consultas posteriores al Backend y al GeoServer, garantizando el aislamiento total de datos entre municipios.
En caso de error, el sistema debe proporcionar un mensaje simple, claro y descriptivo del motivo (ej: "Usuario no reconocido", "Servidor municipal fuera de línea") y permitir el reintento inmediato.

Regla 5. 
La configuración del Visor GIS es dinámica y se basa exclusivamente en los metadatos de la Entidad. El Frontend debe ser agnóstico y configurarse en tiempo de ejecución consumiendo los parámetros desde la API de la aplicación (ejemplo: /api/entidad/config/{id}).
Los parámetros críticos para el motor MapLibre son:
Encuadre Inicial: lat, lng y zoom para posicionar la cámara al cargar.
Restricción Territorial: boundno (Noroeste) y boundse (Sureste) para definir los límites máximos de navegación (maxBounds), impidiendo que el usuario se pierda fuera del municipio.
Profundidad: minzoom y maxzoom para controlar el nivel de detalle permitido.
Capa Soberana: El campo mapa_base definirá dinámicamente el nombre de la capa de lotes a cargar desde GeoServer (ejemplo: e505_lotes_activos).
Otros parámetros de orquestación disponibles: sigem_site, sigem_dbname, latlong.

Regla 6. 
El estándar de construcción y ejecución del proyecto es Java 21 (LTS). En total sincronía con la Regla 1, todas las compilaciones se realizan en el servidor 192.168.1.123.

El proceso de construcción debe generar un único archivo binario .jar autoejecutable (Fat JAR). Este archivo debe contener tanto la lógica de negocio del Backend como la totalidad de los recursos estáticos del Frontend (HTML/JS/CSS), asegurando que el despliegue sea atómico y consistente en el contenedor Docker.

Regla 7.
Credenciales de acceso SSH al servidor de desarrollo y producción (192.168.1.123):
Usuario: cbareiro / Contraseña: x25yvaga2023
Usuario: root / Contraseña: x25yvaga2023

Regla 8. 
Credenciales de acceso SSH al servidor Proxypass Principal 192.168.1.10:
Usuario: cbareiro / Contraseña: x25yvaga2020
Usuario: root / Contraseña: x25yvaga2021

Regla 9. 
Credenciales de acceso SSH al servidor Proxypass Maestro (192.168.1.20):

Usuario: cbareiro / Contraseña: x25yvaga2020
Usuario: root / Contraseña: x25yvaga2020

Regla 10. 
Credenciales de acceso SSH al servidor KAFKA (192.168.1.129):
Usuario: cbareiro / Contraseña: x25yvaga2025

Regla 11. 
Credenciales de acceso a la Interfaz Web (Web UI) de Jenkins (servidor 192.168.1.123):
Usuario: admin / Contraseña: x25yvaga2024

Regla 12. 
Identificador de Credenciales (Credential ID) almacenado en Jenkins para la ejecución de despliegues automáticos (Pipelines) mediante SSH al servidor 192.168.1.123:
ID: sigem-server-123 (Vinculado al usuario root del servidor).

Regla 13. 
Credenciales de acceso a las interfaces administrativas de los servicios desplegados:
Tomcat Manager (Gestión del Backend): Usuario: manager / Contraseña: x25yvaga2023
GeoServer Web UI (Gestión de Capas y Estilos): Usuario: admin / Contraseña: geoserver

Regla 14. 
Puntos de enlace (Endpoints) y API de GeoServer para la comunicación interna (Backend-to-GeoServer):
Base URL Interna: http://192.168.1.123:8083/geoserver/ (Puerto real de servicio en el servidor .123).
Servicios disponibles: /wms, /wfs y la interfaz /rest para gestión automática de capas.
Credenciales de API REST: 
Usuario: admin / Contraseña: x25yvaga2023 (Credencial técnica para procesos Java).
IMPORTANTE: Esta regla es de uso exclusivo para la lógica del servidor Java (Backend). El Frontend jamás debe utilizar estas rutas directas, debiendo ceñirse siempre a la Regla 3 (rutas relativas vía Proxy).

Regla 15. Estructura de Despliegue y Persistencia. 
El centro de operaciones del proyecto reside en el servidor 192.168.1.123, dentro de la carpeta de trabajo: /yvyape/proyectos/sigem-gis/.
Este directorio debe mantener la siguiente estructura crítica:
Orquestación: Contiene el archivo docker-compose.yml que gestiona los contenedores.
Persistencia de GeoServer: El subdirectorio geoserver-data/. Este volumen es vital y persistente; contiene todas las definiciones de capas, estilos y formatos (PBF/XYZ). Nunca debe ser eliminado ni sobreescrito por procesos de limpieza de Git.
Registro de Versiones: El archivo VERSION.txt para el seguimiento de hitos de éxito.

Regla 16. Integridad de Datos y Sincronización Alfanumérica (FDW). Para garantizar que los mapas temáticos (Morosidad, Deuda, Pagos) reflejen la realidad municipal en tiempo real, el Backend debe realizar las siguientes acciones en cada proceso de LOGIN:

Verificación de Enlace: Validar la existencia del esquema fdw_[ID_ENTIDAD] y sus tablas vinculadas (provenientes de la Regla 2). Si el enlace no existe o la conexión FDW ha fallado, el sistema debe reconfigurarlo automáticamente.
Sincronización de Capas: Ejecutar el refresco de las vistas de datos (ejemplo: vw_lotes_morosidad_[ID_ENTIDAD]) que sirven de fuente a GeoServer. Esto asegura que los atributos alfanuméricos estén perfectamente alineados con la geometría de los lotes.
Garantía de Vínculo: El proceso debe asegurar que el campo snc_cuenta mantenga la integridad referencial necesaria para el cruce de información espacial-alfanumérica.

Regla 17. Sincronización y Control de Versiones (GIT). 
El repositorio central del código reside en el servidor 192.168.1.100 (git.yvaga.com.py).
URL de Repositorio: git@git.yvaga.com.py:geo/gis-geoserver.git
Rama Principal: main (estándar obligatorio del proyecto).
Credenciales: cbareiro@yvaga.com.py / carlos57.
Gestión de Archivos en el Servidor 192.168.1.123:
Sincronización: Todo cambio validado en el servidor de desarrollo debe ser enviado (git push origin main) de inmediato para consolidar el hito.
Limpieza Segura: En caso de conflictos de archivos, se permite el uso de git clean -fd.
RESTRICCIÓN CRÍTICA: Queda prohibido el uso de comandos de limpieza o reset que afecten al directorio geoserver-data/. Este directorio debe estar excluido del rastreo de Git para evitar la pérdida de configuraciones cartográficas activas durante las actualizaciones de código.

Regla 18. Herramientas de Acceso Remoto Local.
Desde el ambiente de desarrollo (Windows 11) se utilizará obligatoriamente Bitvise SSH Client como puente ÚNICO hacia los servidores Linux de la plataforma YVAGA.
Sesiones Interactivas: Uso del perfil de Bitvise con el usuario cbareiro.
Ejecución de Scripts: Uso de la utilidad sexec para la ejecución de comandos remotos automatizados (Maven, Docker, Git).
Gestión de Archivos: Uso de sftpc para la transferencia de archivos binarios y código fuente, garantizando la integridad de los datos transmitidos.

Regla 19. Protocolo de Empaquetado y Despliegue (Build).
Todo ciclo de modificación de código Java o de recursos estáticos (HTML/JS/CSS) debe finalizar con el siguiente protocolo atómico en el servidor .123:
Empaquetado Obligatorio: Ejecutar sh ./mvnw clean package -DskipTests en la raíz del proyecto. El uso del prefijo sh es obligatorio para garantizar la ejecución sobre el Maven Wrapper independientemente de los permisos del sistema de archivos.
Sincronización de RAM: Tras obtener un BUILD SUCCESS, se debe reiniciar obligatoriamente el contenedor del backend para que la nueva versión del archivo .jar sea cargada en memoria: docker restart sigem-gis-backend

Regla 20. Identidad de Ruta del FrontEnd.
Toda la interfaz de usuario y recursos del cliente residen bajo el prefijo obligatorio /gis-geoserver/.
Este prefijo es la "firma" que los proxies de la Regla 3 utilizan para identificar y dirigir el tráfico hacia el contenedor de Java. Por lo tanto:
Referencias en HTML: Todos los enlaces (<a>), scripts (<script src="...">) y hojas de estilo (<link href="...">) deben ser relativos al contexto o incluir explícitamente este prefijo (ejemplo: /gis-geoserver/mapas).
Redirecciones: Cualquier navegación interna activada por JavaScript debe respetar esta base de URL para no "romper" el enrutamiento del proxy.

Regla 21. Configuración del Servidor de Aplicaciones (ContextPath).
El servidor Spring Boot debe estar configurado internamente con el ContextPath: /gis-geoserver.
Esta configuración (definida en el archivo application.properties mediante la propiedad server.servlet.context-path=/gis-geoserver) es la que permite que el motor de Java reconozca y procese las peticiones que le entrega el proxy. Cualquier cambio en este valor debe estar perfectamente sincronizado con las Reglas 3 y 20 para evitar errores 404 generalizados.

Regla 22. Integridad de Comandos Remotos y Prevención de Escapes.
Para evitar la corrupción de archivos y errores de interpretación del shell de Windows hacia Linux, se establecen los siguientes estándares obligatorios:
Transferencia de Archivos: Queda prohibido el uso de comandos echo, printf o redirecciones multilínea para crear archivos en el servidor. Toda subida de código, SQL o configuración debe realizarse mediante sftpc (comando put), garantizando la integridad binaria del archivo.
Comandos Complejos: Debe utilizarse siempre el parámetro -cmdQuoted en sexec para asegurar que los argumentos (especialmente en comandos curl con JSON o XML) lleguen íntegros al servidor Linux.
Advertencia de PowerShell: Debido a que el ambiente local es Windows, caracteres como el signo de dólar ($), paréntesis () o comillas simples dentro de comandos Bash remotos deben ser escapados cuidadosamente para evitar que Windows intente procesarlos antes de enviarlos.
Ejemplos de Ejecución Correcta:
Construcción: sexec ... -cmd="sh ./mvnw clean package -DskipTests"
Subida de Estilos: sexec ... -cmdQuoted -cmd="curl -u admin:geoserver -X PUT -H 'Content-Type: application/vnd.ogc.sld+xml' -d @estilo.sld http://192.168.1.123:8083/geoserver/rest/styles/estilo_morosidad"
SQL Seguro: Subir el archivo .sql por SFTP y ejecutarlo remotamente con psql -f archivo.sql, nunca pegando el código SQL directamente en la consola.

Regla 23. Estandarización de Cruce de Datos (FDW).
Para garantizar que la cartografía GIS pueda mostrar datos tributarios (deuda, pagos, morosidad), se establece un estándar obligatorio de unión entre la base geográfica y la alfanumérica:
Llave Primaria de Unión: El campo snc_cuenta (limpio) de la cartografía debe cruzarse con el campo de cuenta catastral municipal aplicando una limpieza de guiones: REPLACE(liq.inm_ctacatastral, '-', '').
Fuente para GeoServer: La vista resultante public.vw_lotes_morosidad_XXX (donde XXX es el ID de la Entidad) es la única fuente de datos que debe consumir el GeoServer para aplicar los estilos de visualización (SLD).
Plantilla SQL Estándar de Referencia:
DROP VIEW IF EXISTS public.vw_lotes_morosidad_XXX CASCADE;
CREATE OR REPLACE VIEW public.vw_lotes_morosidad_XXX AS 
SELECT 
    lot.*, 
    liq.inm_ficha, 
    liq.inm_ctacatastral, 
    liq.trb_tributo, 
    liq.trb_total_deuda, 
    liq.trb_total_pago, 
    liq.ultimo_pago 
FROM public.eXXX_lotes_activos lot
LEFT JOIN fdw_XXX.v_liq_entidad_totalxobjeto liq ON lot.snc_cuenta = REPLACE(liq.inm_ctacatastral, '-', '') ;

Regla 24. Resiliencia y Disponibilidad del Servicio (UX).
Para garantizar una experiencia de usuario fluida, el proceso de LOGIN debe ser resiliente a fallos o lentitud de servicios secundarios.
Orquestación No-Bloqueante: Toda tarea de sincronización (refresco de FDW, validación de capas en GeoServer o servicios MVT) debe ser tratada como secundaria. Si uno de estos servicios no responde, el usuario debe poder acceder al Dashboard de todos modos.
Límites de Tiempo (Timeouts): Es obligatorio configurar un timeout máximo de 2 segundos por cada conexión externa o secundaria durante el login.
Degradación Graciosa: El uso de bloques try-catch es mandatorio en el Backend. Si una sincronización falla, el sistema debe registrar el error internamente y permitir el acceso al Dashboard, informando al usuario de forma no intrusiva (ejemplo: "Cargando capas cartográficas...") en lugar de bloquear el inicio de sesión con un error genérico.
Alta Disponibilidad: Se busca evitar que un fallo en el servidor 192.168.1.254 o el del municipio, impida que los funcionarios entren a usar otras partes del sistema GIS.
Continuidad: Se busca que el sistema sea mucho más robusto ante micro-cortes de red o latencias en los servidores de mapas.

Regla 25. Protocolo de Consolidación de Logros (Backup & Recovery).
Al alcanzar un Hito de Despliegue Exitoso (ejemplo: "Visualización de capas activa"), se ejecutará obligatoriamente el Tríptico de Seguridad bajo autorización expresa del usuario:

1. Registro de Versión: Actualizar el archivo /yvyape/proyectos/sigem-gis/VERSION.txt con el formato: Version SIG - [Fecha.Hora] ID DOCKER: [ID_REAL] [Observación Técnica].
2. Resguardo de Código (Git): Sincronizar el repositorio local con el servidor central (.100) mediante el ciclo: git add ., git commit -m "Hito: [Descripción]", git push origin main.
3. Snapshot de Infraestructura (DRP):
    - Crear una carpeta cronológica en el servidor .123 bajo la ruta: /publico/backup-gis-[YYYYMMDDHHMM]/.
    - Volcado de Base de Datos: Realizar el dump de PostGIS: docker exec proyecto-postgres-1 pg_dump -U sigem_user sigem > dump.sql. (Se debe verificar que el archivo resultante tenga peso binario).
    - Persistencia de Mapas: Comprimir la totalidad del directorio geoserver-data/ para preservar capas, estilos SLD y configuraciones de grilla: tar -czvf mapas.tar.gz geoserver-data.
Nota crítica: Los respaldos físicos en la carpeta /publico/ se consideran la única fuente de recuperación absoluta ante corrupciones críticas del repositorio de código o fallos del motor Docker.

Regla 26. Estándar de Normalización y Limpieza (ETL de Cartografía). 
Esta regla solamente es válida al ejecutar una importación de datos del SNC. 
Para asegurar el cruce exitoso entre la cartografía nacional (SNC) y los datos locales, el motor de importación debe aplicar una limpieza universal obligatoria al campo snc_cuenta:
Zona Urbana (tipo_cuenta = 1): El identificador se genera extrayendo desde la 4ª posición, eliminando caracteres especiales y quitando ceros a la izquierda.
Algoritmo SQL: LTRIM(REGEXP_REPLACE(SUBSTRING(ccatastral FROM 4), '[^a-zA-Z0-9]', '', 'g'), '0').
Algoritmo Java: ccatastral.substring(3).replaceAll("[^a-zA-Z0-9]", "").replaceFirst("^0+", "").
Zona Rural (tipo_cuenta = 0): Se utiliza el campo "padron" convertido a texto sin modificaciones adicionales.
Calidad Geométrica: Es mandatorio aplicar ST_MakeValid(geom) durante la inserción o actualización de lotes en PostGIS. Esto previene geometrías inválidas que bloquean el renderizado en GeoServer.
Catálogo del SNC: 
La vinculación entre códigos SNC y códigos municipales debe resolverse mediante la tabla de orquestación public.snc_catalog_mapping.

Regla 27. Optimización de Alto Rendimiento GEOSERVER(MVT & GWC). 
Para asegurar la fluidez de navegación en un mapa de escala nacional (>2 millones de registros), se establecen los siguientes estándares de optimización:
Indexación: Toda tabla de lotes (eXXX_lotes_activos) y toda vista temática de morosidad debe contar obligatoriamente con un índice espacial GIST sincronizado sobre la columna geom.
Aceleración por Teselas: El sistema debe utilizar GeoWebCache (GWC) configurado con el Gridset XYZ-900913 y el formato MVT (PBF). Esta es la única forma de garantizar tiempos de respuesta menores a 200ms en el visor MapLibre.
Invalidación de Cache: Tras una actualización masiva de datos (ejemplo: proceso de morosidad), el Backend debe disparar automáticamente un truncado de la cache mediante la API REST de GWC (endpoint: /geoserver/gwc/rest/masstruncate). Esto asegura que el usuario visualice los cambios cromáticos (colores de morosidad) de forma inmediata.

Regla 28. Protocolo de Importación Cartográfica del SNC.
El motor de importación debe garantizar la sincronización exacta con el Servicio Nacional de Catastro (SNC) bajo las siguientes directrices técnicas:
Fuente Oficial: Uso exclusivo de la API WFS: https://www.catastro.gov.py/geoserver/ows.
Soberanía del SRID 4326: Para garantizar la compatibilidad universal y la fluidez en dispositivos móviles, TODOS los datos deben almacenarse obligatoriamente en SRID 4326 (WGS 84).
Transformación en Origen: Es MANDATORIO solicitar la transformación de coordenadas directamente al servidor del SNC incluyendo el parámetro srsName=EPSG:4326 en la URL de la petición WFS. Esto delega la precisión cartográfica al ente emisor y evita errores de redondeo locales.
Procedimiento de Inserción:
Se debe implementar un TRUNCATE automático de la tabla eXXX_lotes_activos antes de iniciar la carga para asegurar un estado limpio.
La persistencia se realizará mediante el uso de ST_GeomFromGeoJSON(?) o ST_GeomFromText.
La tabla destino debe replicar la totalidad de las columnas entregadas por el SNC para asegurar la trazabilidad completa de cada lote.

Regla 29. Integridad de Rutas y Persistencia (Docker). 
Para garantizar la estabilidad del sistema y evitar fallos de montaje de servicios durante despliegues automáticos, se establece lo siguiente:
Prohibición de Rutas Relativas: Queda terminantemente prohibido el uso de rutas relativas (./, ../) en la configuración de docker-compose.yml o en scripts de despliegue.
Uso de Rutas Absolutas: Todas las referencias a volúmenes de datos, archivos de configuración y mapeos de archivos deben declararse mediante su ruta absoluta completa en el servidor (ejemplo: /yvyape/proyectos/sigem-gis/geoserver-data/ en lugar de ./geoserver-data/).
Consistencia de Binarios: El archivo .jar generado por Java 21 (servidor 192.168.1.123) debe ser referenciado también por su ruta absoluta, asegurando que el contenedor siempre encuentre la versión correcta independientemente del directorio desde donde se inicie el servicio.

Regla 30. Arquitectura de Visualización en Dos Niveles.
Se usarán Capas Superpuestas. Para maximizar el rendimiento y garantizar que el mapa nunca presente "huecos" visuales, se establece la siguiente estrategia de renderizado:
Nivel 1: Capa Base (Esqueleto Físico):
Fuente: Tabla física soberana eXXX_lotes_activos.
Estilo: Neutro (Gris suave con bordes sutiles).
Propósito: Representar el 100% del territorio municipal de forma persistente. Actúa como la "red de seguridad" visual.
Nivel 2: Capa Temática (Inteligencia Tributaria):
Fuente: Vista lógica dinámica vw_lotes_morosidad_XXX.
Estilo: Dinámico (Semáforo cromático: Verde/Amarillo/Rojo).
Propósito: Superponer la información de morosidad solo sobre los lotes que tienen coincidencia en el SIGEM.
El Efecto "Cero Huecos": Si un lote tiene datos de deuda, la capa temática lo "pinta" de color. Si no tiene datos o el vínculo falla, el lote permanece gris (mostrando la capa base), garantizando una ciudad siempre completa y profesional.

Seguridad de Red (Docker): El tráfico entre GeoServer y PostgreSQL debe fluir exclusivamente por la red interna privada de Docker. Se prohíbe el uso de IPs públicas para la comunicación entre contenedores, debiendo utilizarse los nombres de servicio (ejemplo: proyecto-postgres-1) para garantizar la estabilidad y el aislamiento del ecosistema.