La página `/changelog` y `/actualizaciones` mostraba datos hardcodeados en `@php` dentro del blade, sin conexión con el FIXLOG real del proyecto. No existía trazabilidad verificable de cambios para auditoría ISO 27001.

La ruta era un closure que devolvía una vista con todos los datos estáticos en un bloque `@php`. El FIXLOG existía como documentación interna pero no estaba expuesto en ninguna interfaz.

Creación de `ChangelogController::index()` que (1) contiene el historial semántico de versiones como array estático PHP y (2) parsea `docs/fixes/FIXLOG.md` con regex para extraer cada entrada `FIX-YYYYMMDD-NNN`. La vista muestra ambas secciones: historial de versiones curado + tabla "Trazabilidad de…

`https://laft360.com/changelog` carga con título "LAFT360 v1.03", sección "Trazabilidad de Cambios Técnicos" visible con badge "7 registros", todas las filas del FIXLOG renderizadas con Fix ID, fecha, descripción, archivo y estado correcto.

El wizard no capturaba los campos exigidos por la Circular Externa V2: Paso 1 sin datos del sujeto obligado (tipo societario, estado registro mercantil, CIIU, ámbito, RL, RF); Paso 2/3 sin HV OC estructurada ni estado/link ONAC; Paso 5 sin sección de Debida Diligencia (DDI checkboxes) ni campo de mecanismo de comunicación.

Vista creada antes de que se definieran los requisitos V2 completos. **Fix (sin tocar lógica de guardado):** - Paso 1: secciones "Sujeto obligado" (tipo_societario, estado_registro_mercantil), "Actividad económica" (ciiu_principal, ciiu_secundario, descripcion_actividad, modalidad_transporte, ambito_operacion, direccion_principal), "RL" y "RF" con todos sus campos. - Paso 2/3: reestructuró HV OC — nivel_educativo + institucion_educativa, especialidad + tipo_especialidad (select) + institucion_especialidad, experiencia_meses; sección ONAC: cert_onac_estado (select pendiente/si/no) + link_verificacion_onac. - Paso 5: nueva sección "Debida diligencia" con dd_simplificada, dd_intensificada, operaciones_intentadas y criterio_ddi como checkboxes múltiples (5 valores SET); nueva sección "Divulgación y comunicación" con estrategia_divulgacion y mecanismo_comunicacion (textareas).

`php artisan route:list` arranca → Laravel carga sin error de compilación. Error de `view:cache` es de vista ajena (componente `label` de API tokens — preexistente).

`supertransporte_resultado_objetivo.criterio_ddi` era `VARCHAR(500)` de texto libre. La Circular Externa V2 define exactamente 5 criterios de DDI intensificada (multi-opción). El campo no garantizaba integridad referencial ni facilitaba reportes por criterio.

Campo sin restricción de dominio. V2 formaliza los 5 criterios: `mayor_riesgo`, `pep`, `paises_no_cooperantes`, `jurisdicciones_alto_riesgo`, `activos_virtuales`.

`MODIFY COLUMN criterio_ddi SET(...)`. MySQL `SET` devuelve string con coma al leer, no JSON — se agregaron `getCriterioDdiAttribute` (explode) y `setCriterioDdiAttribute` (implode) en el modelo. Sin cast `'array'` para evitar conflicto con el formato nativo de MySQL SET.

`INFORMATION_SCHEMA.COLUMNS` confirma `set('mayor_riesgo','pep','paises_no_cooperantes','jurisdicciones_alto_riesgo','activos_virtuales')`.

`supertransporte_reportes` carecía de 21 campos exigidos por la Hoja "Datos Básicos" de la Circular Externa / Res. 2328/2025: tipo societario, estado registro mercantil, CIIU principal/secundario, descripción actividad, modalidad transporte, ámbito operación, dirección, datos RL (nombre, tipo doc, num doc, correo, SIREL, fecha SIREL) y datos RF (nombre, tipo id, num id, SIREL, presentó informe, núm. hallazgos, plan de mejoramiento).

Implementación original del módulo sólo capturaba metadatos del reporte (período, régimen, CSS score) sin los campos de identificación del sujeto obligado exigidos en V2.

`ALTER TABLE supertransporte_reportes ADD COLUMN ...` × 21 columnas. Modelo actualizado con fillable y casts correspondientes.

`COUNT(*) = 21` en `INFORMATION_SCHEMA.COLUMNS` para las columnas nuevas.

`SarlaftReporteService::PERIODOS_2026` usaba día 30/31 como límite en P1/P3/P4 (debía ser día 10). P2 tenía fechas abril-junio en lugar de mayo-julio (primer reporte de transición). La tabla `supertransporte_oc` carecía de campos de HV estructurada y certificación ONAC exigidos por la Circular Externa V2. No existía historial independiente de novedades OC.

Implementación original no reflejaba la Circular Externa Supertransporte + Res. 2328/2025 + Res. 4607/2026. P2 tiene inicio especial de transición (mayo, no abril); el límite de todos los períodos es día 10 (no fin de mes).

- `PERIODOS_2026`: P1 límite → `2026-04-10`; P2 rango → `2026-05-01 / 2026-07-31`; P3 rango → `2026-08-01 / 2026-09-30`, límite → `2026-10-10`; P4 límite → `2027-01-10`. - `supertransporte_oc`: ALTER ADD 6 columnas: `institucion_educativa`, `tipo_especialidad`, `institucion_especialidad`, `experien…

`INFORMATION_SCHEMA.COLUMNS` confirma 6 columnas nuevas en `supertransporte_oc`. `SHOW CREATE TABLE supertransporte_oc_novedades` confirma estructura correcta.

Martha Lucia Cadena Mancera (user_id=57, team_id=53) veía el overlay "Actualiza tu plan" en `/consultas/directa` y no podía ejecutar ninguna consulta.

`subscription_plans.plan_code = 'paquete_10_consultas'` para el plan de Martha. `PlanGateService::getCurrentPlanCode()` aplica `strtoupper()` → `'PAQUETE_10_CONSULTAS'` que NO existe en el array `PLAN_LEVELS`. El método `getCurrentPlanLevel()` resuelve `PLAN_LEVELS['PAQUETE_10_CONSULTAS'] ?? 0` = nivel 0 (`LISTAS_RESTRICTIVAS`). La vista `/consultas/directa` está envuelta en `<x-plan-gate min-plan="BASIC">` que requiere nivel ≥ 1. `0 < 1` → gate bloquea toda la vista con el overlay de upgrade.

`UPDATE subscription_plans SET plan_code = 'basic' WHERE id = 9 AND plan_code = 'paquete_10_consultas'` — alinea el plan_code con el valor reconocido (`BASIC` → nivel 1). Solo el equipo 53 (Martha) tenía activo ese plan_id. Sin cambio de código ni deploy.

`SELECT id, plan_code, plan_type FROM subscription_plans WHERE id = 9` → `plan_code = 'basic'`. La limpieza de caché `team_ready:53` fue aplicada. Al siguiente acceso, `PlanGateService::canAccess(team_53, 'BASIC')` retornará `true` y el formulario será visible.

`/admin/onboarding` mostraba 20 solicitudes pero `/admin/teams/services` mostraba 25 teams. Todos los super-admins deberían ver el mismo conjunto completo.

`OnboardingController::index()` lista `UserOnboardingRequest` (no `Team`). Los teams 37–46 fueron creados directamente vía importación sin pasar por el flujo de onboarding, por lo que no tenían fila en `user_onboarding_requests` y no aparecían en la vista.

INSERT de 10 registros sintéticos en `user_onboarding_requests` (status=`approved`, referral_source=`direct_import`) para los teams 37–46, enlazando `team_id`, `company_id`, `company_name`, y el usuario owner de cada team. Sin cambio de código.

`SELECT COUNT(*) = 29 active` + LEFT JOIN confirmando que todos los 25 teams tienen `tiene_onboarding = SI`.

"La recepción pública aún no está habilitada en este entorno." al intentar generar QR en `/recepcion/clientes`

Las tablas `public_kyc_links` y `public_kyc_submissions` no existían en `worlvetting_v360`. Los modelos y controladores estaban completos pero las migraciones nunca fueron creadas ni ejecutadas. El guard `publicKycTablesAvailable()` las detectaba ausentes y redirigía con ese mensaje.

Creación directa de ambas tablas vía SQL en `worlvetting_v360` (script: `create_public_kyc_tables_20260504.sql`). Incluye PK, índices, y FK hacia `teams`, `users`, `business_flows`, `contrapartes`, `business_flow_executions`.

`SHOW TABLES LIKE 'public_kyc%'` + `DESCRIBE` de ambas tablas confirmó estructura completa con todas las columnas, UNIQUEs e índices.