Version: 1.0
Fecha: 23 de Mayo, 2026
Estado: INFORMATIVO - Items no criticos a planificar
Arquitecto: Carlos Alberto Torres Camargo
Inventario de items detectados durante o despues de la integracion de stack-2026-05-23 que no son criticos para la operacion pero merecen atencion en sprints futuros. Cada item incluye severidad, esfuerzo estimado, ventana sugerida y responsable.
| Aspecto | Valor |
|---|---|
| Severidad | Alta (seguridad) |
| Esfuerzo | 10 minutos |
| Ventana sugerida | ASAP |
| Responsable | Arquitecto licenciante |
Contexto: durante el deploy se detecto que imagenes Docker previas del simappe-config-server en el registry interno del cliente contienen el PAT GitHub del licenciante en su JAR (application-*.yml). Aunque la imagen actual ya tiene defaults vacios, las imagenes previas siguen disponibles via docker pull con un tag historico.
Accion:
SimappeConfig.Verificacion: intento de pull del repo SimappeConfig con el PAT viejo debe fallar.
| Aspecto | Valor |
|---|---|
| Severidad | Baja (warning) |
| Esfuerzo | 15 minutos + tests |
| Ventana sugerida | Proximo sprint Nebula |
| Responsable | Equipo Centrica |
Contexto: Hibernate dispara WARN al arrancar nebula-masters y nebula-accounting-core:
HHH000511: The 16.11.0 version for [org.hibernate.dialect.OracleDialect] is no longer supported.
The minimum supported version is 19.0.0.
El driver ojdbc11 detectado por Hibernate es 16.11. Oracle XE 21 (server) si esta soportado, pero la version del client driver es vieja.
Accion: en nebula-masters/pom.xml y nebula-accounting-core/pom.xml:
<dependency>
<groupId>com.oracle.database.jdbc</groupId>
<artifactId>ojdbc11</artifactId>
<version>23.5.0.24.07</version> <!-- o version mas reciente que 19.0 -->
<scope>runtime</scope>
</dependency>
Verificacion post-fix:
docker logs nebula-accounting-core 2>&1 | grep "HHH000511"
# Vacio = WARN eliminado
hibernate.dialect=OracleDialect hardcoded| Aspecto | Valor |
|---|---|
| Severidad | Baja (warning + side effect en metadata) |
| Esfuerzo | 30 minutos + tests funcionales |
| Ventana sugerida | Proximo sprint Nebula |
| Responsable | Equipo Centrica |
Contexto: ver Incidente 4.
nebula-accounting-core/src/main/java/com/centrica/nebula/accounting/core/config/MultiTenantJpaConfig.java:286 tiene:
properties.put("hibernate.dialect", "org.hibernate.dialect.OracleDialect");
Esto fuerza dialect Oracle en TODAS las connections, incluido el template Postgres. Hibernate 6.6+ autodetecta dialect correctamente sin el hardcode.
Accion: remover la linea. Validar smoke funcional: que las queries Oracle de negocio sigan funcionando (deben, porque la connection es Oracle y autodetecta OracleDialect) y que el WARN HHH000339 desaparezca.
Verificar si el commit que introdujo el hardcode (15c7cac fix: set OracleDialect explicitly for Hibernate sequence SQL generation) abordaba un problema concreto. Si si, evaluar si Hibernate 6.6+ aun requiere el workaround. Si no, eliminar.
Duplicate generator name simappe_seq_gen| Aspecto | Valor |
|---|---|
| Severidad | Baja (warning Hibernate) |
| Esfuerzo | 1-2 horas (varias entities) |
| Ventana sugerida | Sprint dedicado a deuda tecnica |
| Responsable | Equipo Centrica |
Contexto: Hibernate WARN al arrancar:
HHH000069: Duplicate generator name simappe_seq_gen
Aparece 1 vez en nebula-masters, 2 veces en nebula-accounting-core. Hibernate detecta varias entities con @SequenceGenerator(name="simappe_seq_gen", sequenceName="...") con el mismo name pero distintos sequenceName o atributos.
Accion: revisar todas las entities que usan @SequenceGenerator y darles nombre unico (<entity>_seq_gen) o consolidar la declaracion via clase base si efectivamente es la misma sequence DB.
Verificacion post-fix:
docker logs <servicio> 2>&1 | grep "HHH000069"
# Vacio = WARN eliminado
prod-config con las nuevas propiedades| Aspecto | Valor |
|---|---|
| Severidad | Media (depende del plan de promocion a prod) |
| Esfuerzo | 30 minutos |
| Ventana sugerida | Antes de promover el upgrade a produccion |
| Responsable | Arquitecto + equipo Centrica |
Contexto: el upgrade stack-2026-05-23 solo sincronizo dev-config, local-config y localhost-config con las nuevas propiedades (multitenant flags, flyway, notification, db-encryption-key). prod-config se excluyo explicitamente por decision del arquitecto.
Accion (cuando se decida promover a prod):
feature/sync-prod-stack-2026-05-23 en simappeconfig.prod-config/:
application-common.yml: agregar db-encryption-key, lazy-initialization, virtual-threads, forward-headers-strategy.simappe-client-prod.yml: agregar multitenant.mongo.enabled=false y bloque notification.* con enabled=false.simappe-admin-prod.yml: agregar spring.flyway.*.application-prod.yml: rename redis.pool.* -> redis.lettuce.pool.*.main (recordar excepcion config-server).SPRING_PROFILES_ACTIVE=common,prod en el .env de prod| Aspecto | Valor |
|---|---|
| Severidad | Media (depende del plan de promocion a prod) |
| Esfuerzo | 5 minutos |
| Ventana sugerida | Junto con 2.5 |
| Responsable | Equipo Centrica |
Contexto: mismo razonamiento que en DEV. Sin common activo, application-common.yml no se carga.
Accion: crear o actualizar el .env de cada grupo de compose en el server prod del cliente con SPRING_PROFILES_ACTIVE=common,prod (en lugar de solo APP_PROFILE=prod).
simappeconfigserver en el workspace del licenciante| Aspecto | Valor |
|---|---|
| Severidad | Alta (higiene del proceso de release) |
| Esfuerzo | 30 minutos |
| Ventana sugerida | Proximo release del licenciante |
| Responsable | Arquitecto licenciante |
Contexto: el hot fix de simappeconfigserver/application-*.yml (parametrizacion con defaults vacios) se aplico directamente en el workspace del cliente con autorizacion uno-a-uno del arquitecto. Esto es excepcion a la regla "no cambios locales en repos Simappe del cliente".
Accion: replicar el mismo cambio en el repo origen GitHub (<owner>/SimappeConfigServer) para que viaje a futuros clientes sin necesidad de hot fix. Bump de version y commit en develop.
deploy-centrica-dev.sh para usar alias SSH| Aspecto | Valor |
|---|---|
| Severidad | Baja (operacional) |
| Esfuerzo | 30 minutos (todos los repos) |
| Ventana sugerida | Proximo release del licenciante |
| Responsable | Arquitecto licenciante |
Contexto: los scripts deploy-centrica-dev.sh en cada repo Simappe usan IP hardcoded 200.118.43.29:2202 que requiere VPN. Durante el deploy se uso el alias SSH nodo-01 como bypass.
Accion: actualizar los 9 scripts (uno por repo) para usar el alias SSH en lugar de la IP. Documentar el alias requerido en el README del proceso de deploy.
release/2026-05-23 y feature/sync-stack-2026-05-23| Aspecto | Valor |
|---|---|
| Severidad | Baja (limpieza) |
| Esfuerzo | 15 minutos |
| Ventana sugerida | 2-3 semanas post-merge (cuando se confirme que no hay regresion) |
| Responsable | Equipo Centrica |
Contexto: las ramas del upgrade ya estan mergeadas en develop. Mantenerlas indefinidamente genera ruido en la lista de branches.
Accion (en cada repo afectado):
# Eliminar branch remota
git push origin --delete release/2026-05-23
git push origin --delete feature/sync-stack-2026-05-23
# Tag stack-2026-05-23 SE PRESERVA (es el ancla historica de la version)
Importante: NO borrar el tag
stack-2026-05-23. El tag queda como referencia historica al commit del upgrade.
docker-compose.yml.bak.refactor-* en nodo-01| Aspecto | Valor |
|---|---|
| Severidad | Baja (housekeeping) |
| Esfuerzo | 5 minutos |
| Ventana sugerida | 1-2 semanas post-upgrade |
| Responsable | Equipo plataforma Centrica |
Contexto: durante el refactor del compose a patron env_file: .env, se generaron backups docker-compose.yml.bak.refactor-<timestamp> en cada grupo. Una vez confirmada la estabilidad, se pueden depurar.
Accion: en cada grupo de compose:
ls -la ~/docker/compose/<grupo>/docker-compose.yml.bak.*
# Verificar fechas + diff vs actual + eliminar las que ya no aplican
rm ~/docker/compose/<grupo>/docker-compose.yml.bak.refactor-*
simappe-monitor-logs| Aspecto | Valor |
|---|---|
| Severidad | Baja (warnings de retry, no crash) |
| Esfuerzo | 1-2 horas |
| Ventana sugerida | Sprint observability |
| Responsable | Equipo Centrica |
Contexto: logs de simappe-monitor-logs muestran stack traces parciales:
reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.onError
HttpClientConnect$MonoHttpConnect$ClientTransportSubscriber.onError
DefaultPooledConnectionProvider$DisposableAcquire.onError
Sintoma de retries reactivos a algun endpoint que no esta listo durante el bootstrap. Servicio healthy en runtime, solo aparece en arranque.
Accion: identificar a que endpoint intenta conectarse y por que falla inicialmente. Posible: orden de arranque del compose hace que monitor-logs intente conectarse antes que el endpoint este listo.
| Item | Severidad | Esfuerzo | Cuando |
|---|---|---|---|
| 2.1 Rotar PAT GitHub | Alta (seguridad) | 10m | ASAP |
| 2.7 Formalizar fix configserver | Alta (proceso) | 30m | Proximo release licenciante |
| 2.5 Sync prod-config | Media | 30m | Antes de promover a prod |
| 2.6 SPRING_PROFILES_ACTIVE prod | Media | 5m | Antes de promover a prod |
| 2.2 Driver ojdbc11 >= 19 | Baja | 15m + tests | Sprint Nebula |
| 2.3 Remover hibernate.dialect | Baja | 30m + tests | Sprint Nebula |
| 2.4 Duplicate seq generator | Baja | 1-2h | Sprint deuda tecnica |
| 2.8 deploy-centrica-dev.sh alias | Baja | 30m | Proximo release licenciante |
| 2.9 Cleanup branches | Baja | 15m | 2-3 semanas post-merge |
| 2.10 Cleanup compose.bak | Baja | 5m | 1-2 semanas post-upgrade |
| 2.11 Warnings reactor-netty | Baja | 1-2h | Sprint observability |
| Documento | Relacion |
|---|---|
| Incidentes Resueltos | Origen de varios items pendientes (2.7 viene del Incidente 2, 2.3 del Incidente 4) |
| Estrategias Operativas | Procedimientos relevantes para resolver los items |
| Breaking Changes | Cambios cuya activacion controlada esta entre los pendientes (2.5, 2.6) |
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-05-24 | Carlos Torres | Inventario de pendientes post upgrade stack-2026-05-23 |