Levantamiento funcional y gobierno · Maloca

La capacidad de crear y publicar aplicaciones (denominadas soluciones en la plataforma) está gobernada por la matriz de permisos del módulo de gobernanza. Por configuración por defecto basada en el principio de menor privilegio, los roles con permiso solutions.create son:

• Administrador (acceso total · 72 grants)
• Desarrollador (creador técnico · 9 grants: solutions.c+r+u+d)
• Abogado (litigante publicador · 8 grants: solutions.c+r+u)
• Académico/Investigador (autor de recursos · 9 grants: solutions.c+r+u)

Los demás roles tienen únicamente acceso de lectura (solutions.read). La matriz es modificable en línea por el administrador desde el panel de Gobernanza.

Sí. La publicación con calidad institucional pasa por el workflow formal Curaduría UTDI, modelado con 6 estados y 7 transiciones:

Sin sello → Pendiente revisión → En revisión → Aprobada UTDI ✓
                                            ↘ Rechazada → (Solicitar cambios) → Pendiente

                                   Aprobada UTDI → Revocada → Reenviar a revisión

Para alcanzar el Sello UTDI ✓ azul (nivel de madurez certificada-utdi), la solución debe ser tomada por un Curador UTDI desde la cola de revisión, evaluada y aprobada. El rol Desarrollador puede solicitar revisión (request_review), pero la transición a Aprobada UTDI solo la pueden ejecutar Administrador o Curador UTDI.

Maloca opera con un pipeline de auditoría obligatorio al publicar (api/_audit_pipeline.php) que orquesta cuatro componentes:

• web-check (8 endpoints paralelos: SSL, headers, HTTP security, firewall, block-lists, quality, tech-stack, WHOIS)
• pentest asíncrono contra el dominio
• ClamAV daemon sobre archivos cargados (260× speedup)
• Heurísticas locales (macros VBA, web-shells PHP, JS ofuscado)

Cuando una solución es marcada como critical, la publicación se bloquea automáticamente con HTTP 409. Para solicitudes en revisión, el Curador puede ejecutar reject o request_changes; sobre una solución ya aprobada, revoke retira el Sello UTDI con bitácora en curador_review_log.

Sí. La tabla solutions exige un id_owner (clave foránea a users.id_user, ON DELETE SET NULL para preservar histórico). Adicionalmente, al crear cada autor debe firmar dos consentimientos versionados:

• Habeas Data (habeas_data_consent_at)
• Cesión de propiedad intelectual (ip_assignment_consent_at)

Ambos consentimientos quedan auditados en audit_log con la versión vigente del texto legal. Al aprobar con sello UTDI, también queda registrado utdi_approved_by y utdi_approved_at.

Maloca modela el ciclo de vida en tres dimensiones complementarias:

Dimensión A · Estado operativo (solutions.status):

• draft (borrador no publicado)
• published (publicada, visible al catálogo)
• archived (retirada lógicamente, no borrada)

Dimensión B · Nivel de madurez (solutions.id_maturity):

• idea → prototipo → beta → producción → consolidada → certificada-utdi

Dimensión C · Sello UTDI (solutions.utdi_sello_status):

• not_requested → pending_review → in_review → approved (o) rejected → revoked

Acción	Roles autorizados
status: draft → published	Administrador, Desarrollador, Abogado, Académico (requiere solutions.update + audit OK)
status: published → archived	Administrador, Desarrollador (sobre su propio recurso)
id_maturity (1→6)	Administrador, Curador UTDI (vía workflow Curaduría)
utdi_sello_status	Administrador, Curador UTDI; parcial: Desarrollador (request_review y resubmit)

El sistema aplica el control en workflow_role_permissions (UNIQUE en id_transition, id_role). Una transición sin roles autorizados queda visualmente marcada con un warning rojo dashed en el panel de administración.

Para publicar (mover de draft a published con visibilidad en el catálogo público), Maloca exige:

• Campos obligatorios: nombre, tagline, descripción, categoría, tipo de entregable
• Consentimientos firmados: Habeas Data + cesión de propiedad intelectual
• Pipeline de auditoría OK: el audit pipeline no debe devolver severity='critical'
• Owner asignado: solutions.id_owner no nulo

Para alcanzar el Sello UTDI ✓ (nivel certificada-utdi), adicionalmente se requiere completar el workflow de Curaduría: solicitud → claim por Curador → revisión → aprobación. La revocación es siempre posible por Administrador en cualquier momento.

Maloca cuenta con 10 roles modelados en la tabla roles, todos con icono FontAwesome y color de la paleta DEAJ:

#	Rol	Misión
1	Administrador	Gestionar toda la plataforma
2	Juez / Magistrado	Aportar perspectiva judicial, validar contenido
3	Funcionario Judicial	Gestionar trámites, consultar soluciones
4	Abogado	Contribuir desde la práctica litigiosa
5	Ciudadano	Consultar y retroalimentar
6	Desarrollador	Crear y mantener soluciones tecnológicas
7	Académico / Investigador	Investigar y publicar recursos
8	Curador UTDI	Validar y certificar (Sello UTDI ✓)
9	Mentor	Acompañar a otros usuarios
10	Embajador	Difundir en su seccional (tiers bronce/plata/oro)

Cada rol tiene una ficha técnica con misión, expectativas, permisos y workflows autorizados, accesible desde el panel de administración.

La matriz de control de acceso modela 14 recursos × 5 acciones + 2 especiales = 72 permisos atómicos. Maloca distribuye 136 grants así:

Rol	Grants	Permisos clave
Administrador	72	TODOS los recursos
Juez / Magistrado	8	solutions:r · community:c+r · events:c+r · resources:r · analytics:r · reports:r
Funcionario Judicial	5	solutions:r · community:c+r · events:r · resources:r
Abogado	8	solutions:c+r+u · community:c+r · events:r · resources:c+r
Ciudadano	5	solutions:r · community:c+r · events:r · resources:r
Desarrollador	9	solutions:c+r+u+d · community:c+r · events:r · resources:c+r
Académico	9	solutions:c+r+u · community:c+r · events:r · resources:c+r+u
Curador UTDI	8	solutions:r+u · curaduria:c+r+u+d · audits:r · community:r
Mentor	5	solutions:r · community:c+r · events:r · resources:r
Embajador	7	solutions:r · community:c+r · events:c+r · resources:r · embajadores:r

Ningún rol distinto de Administrador recibe permisos sobre: users, settings, api_tokens, governance, moderation, reports.write, audits.write/delete/export, system.*. Esta restricción es deliberada por seguridad.

Maloca audita todas las acciones de impacto en audit_log, con 198+ entradas vigentes. Categorías auditadas:

• Autenticación: login, logout, login_failed, password_changed, account_locked
• MFA: mfa_enabled, mfa_factor_added, magic_link_used, backup_code_used
• Soluciones: solution_created, solution_published, solution_rating_created
• Curaduría UTDI: curador_claim, curador_approve, curador_reject, curador_revoke
• Moderación: admin_moderation_approve/hide/remove/edit/restore
• Gobernanza: admin_gov_role_create/update, admin_gov_permission_grant/revoke, admin_gov_workflow_toggle
• Administración: admin_report_csj_csv/xlsx/email, admin_user_role_changed
• API pública: api_token_created/revoked, api_request (con rate-limit hits)
• Auditoría externa: solution_audits + audit_findings versionados por SHA-256
• Comentarios moderados por IA: comment_safety_log

La plataforma maneja un rol principal único por usuario (users.id_role) por simplicidad y trazabilidad. Sin embargo, Maloca soporta roles acumulables ortogonales mediante flags y campos enumerados:

• users.is_mentor — Cualquier usuario puede ser adicionalmente Mentor
• users.embajador_tier ('', bronce, plata, oro) — Programa Embajadores progresivo
• users.ramajud_validated — Flag automático para correos @*.ramajudicial.gov.co

Un Funcionario Judicial puede ser también Embajador Oro y Mentor activo, sin colisionar con su rol principal funcional.

El modal "Publicar solución" v2.7.1 implementa validación en vivo con MardukForm y exige:

Campo	Obligatorio	Validación
name	✓	3–200 chars, único por slug
tagline	✓	10–255 chars
description	✓	mínimo 100 chars, Markdown XSS-safe
id_category	✓	FK a categories
id_maturity	✓	1 de 6 niveles
deliverable_type	✓	1 de 9 tipos
habeas_data_consent	✓	checkbox requerido
ip_assignment_consent	✓	checkbox requerido
tags	recomendado	1–8 tags
version_current	auto	v1.0.0 por defecto

El formulario implementa 5 botones de sugerencia IA por campo, un counter con semáforo de calidad y un picker FontAwesome.

Maloca clasifica en cuatro ejes complementarios:

• Categorías temáticas (tabla categories, 10+ valores)
• Tipo de entregable (solutions.deliverable_type, 9 valores: codigo, script, excel, macro, modelo-ia, url, dataset, documento, otro)
• Nivel de madurez (id_maturity, 6 niveles)
• Tags libres (tabla solution_tags N:M, hasta 8 por solución)

Adicionalmente cada solución exhibe el estado del Sello UTDI como insignia visible cuando es approved. La búsqueda del catálogo es multi-token (hasta 8 tokens, filtrados ≥3 chars) con OR sobre todos los campos.

Maloca implementa tres mecanismos complementarios:

• Restricción de unicidad estricta: solutions.slug tiene UNIQUE constraint. HTTP 409 Conflict en duplicado.
• Búsqueda semántica por embeddings: nomic-embed-text 768d (Ollama local, sin costo) + cosine similarity. Si similitud > 0.80, se ofrece vista comparativa.
• Curaduría humana: el Curador UTDI puede rechazar con motivo de duplicidad, enlazando al recurso ya publicado.

La administración funcional del catálogo es colaborativa:

• Curador UTDI — Administra la cola de revisión, otorga/revoca el Sello UTDI, mantiene la calidad mínima del catálogo. Permisos: solutions:r+u + curaduria:c+r+u+d.
• Administrador — Acceso total: crear/editar/archivar cualquier solución, modificar categorías, ajustar permisos.
• Autores (Desarrollador, Abogado, Académico) — Administran sus propias soluciones: metadata, miembros del equipo, versiones, tags inline.

Maloca incorpora IA en doce capas funcionales documentadas, todas con propósito específico y opt-in explícito:

1. Maloca AI · Asistente conversacional (widget Parla 360)
2. Memoria persistente (maloca_chat_memoria)
3. Identidad estable de visitantes (cookie maloca_vid 90d)
4. Contexto por vista (12 handlers path-aware)
5. Visión + emoción de cámara (frame solo en memoria, NUNCA persistido)
6. Web Search Ollama (proxy con rate limit + cache)
7. NL → SQL Visor IA (admin/curador, whitelist 21 tablas, anti-DDL)
8. Iurix Playground (38+ modelos)
9. Iurix Match (dolor→solución con embeddings)
10. Moderación IA (gemma3:27b, política flag, no auto-eliminación)
11. Audit pipeline IA (heurísticas macros/web-shells)
12. Sugerencias IA en formularios (5 botones opt-in)

La plataforma aplica restricciones explícitas:

• Datos sensibles por Ley 1581/2012 (art. 5): origen racial, orientación política, convicciones religiosas, sindicalización, salud, vida sexual, biométricos. No deben ingresar al prompt.
• Datos personales de terceros sin consentimiento explícito documentado.
• Documentos sometidos a reserva judicial (procesos penales de menores, habeas corpus, etc.).
• Información protegida por secreto profesional.

La capa NL → SQL Visor IA opera con whitelist explícita de 21 tablas seguras y bloquea cualquier consulta que toque users.password, users.totp_secret, users.backup_codes, sessions.id_session, api_tokens.token_hash o tablas de cifrado MFA.

Maloca aplica el marco legal colombiano (Ley 1581/2012, Decreto 1377/2013, Decreto 1074/2015, Ley 2300/2023, Circular SIC 001/2024). Considera sensible:

Categoría	Tratamiento
Datos personales (nombres, emails, cédulas)	Cifrados en BD donde corresponde; acceso restringido con audit
Datos sensibles art. 5 (salud, biometría, política, religión, vida sexual)	Prohibida su captura y procesamiento por IA
Datos judiciales (procesos en curso, víctimas)	Solo accesibles a roles autorizados; reserva por ley
Datos de menores (NNA)	Requiere consentimiento de representante legal
Credenciales (passwords, TOTP, backup codes)	AES-256-GCM + bcrypt; master key separada
Datos de pago	Maloca no procesa pagos; N/A
Frames de cámara (visión IA)	Solo en memoria, nunca persistidos

Trazabilidad obligatoria (siempre en audit_log):

• Autenticación: login, logout, login_failed, password_changed, MFA on/off
• Cambios de rol o permisos (admin_user_role_changed, admin_gov_permission_grant)
• Soluciones: creación, edición, publicación, sello UTDI
• Moderación: aprobar/ocultar/eliminar/editar
• Exportaciones de reportes (CSV, Excel, PDF, email)
• Consultas NL→SQL ejecutadas (query + user)
• API pública v1 (token, endpoint, IP, status)

Alertas activas en el dashboard:

• ≥5 login_failed en 10 min desde la misma IP → flag sospecha
• audit_findings con severity='critical' → bloqueo HTTP 409
• Comentario con toxicity > 0.7 o malicious > 0.6 → cola moderación
• solution_audits score < 30 → notificación al curador

Maloca expone los reportes ejecutivos via reports_executive, disponible en 6 formatos:

Formato	URL	Uso típico
CSV	?format=csv&days=30	Importación a Excel/Calc, BI ligero
Excel	?format=xlsx&days=30	Hoja Excel con secciones formateadas
JSON	?format=preview&days=30	Consumo programático
HTML brandeado	?format=html&days=30	Vista web compartible
PDF (autoprint)	?format=pdf&days=7	Impresión institucional
Email	?format=email&days=30	Envío directo al CSJ

Cada reporte agrupa 8 secciones: KPIs principales (17 columnas), Top 5 soluciones, Distribución usuarios por rol, Top 5 categorías, Próximos eventos, Distribución NPS caritas, UTDI recientes, indicadores completos.

La administración funcional está delineada en tres capas:

• Gobierno institucional — Dirección Ejecutiva de Administración Judicial (DEAJ) — UTDI. Lineamientos estratégicos, aprobación de roadmap, validación de calidad institucional del Sello UTDI, firma de convenios externos.
• Administración técnica — Rol Administrador (cuenta nominal por la UTDI). Gestiona usuarios, configuración, matriz de permisos, workflows, integraciones y monitoreo.
• Curaduría operativa — Rol Curador UTDI. Mantiene la calidad del catálogo: revisa soluciones, otorga/revoca el Sello UTDI, modera contenido reportado por IA.

Los tres niveles colaboran a través del panel /pages/admin.php y la página pública de gobernanza.

La operación incidente/soporte se canaliza así:

Canal	Responsable	SLA objetivo
Email institucional admin@marduk.pro	UTDI · admin nominal	24h hábiles
Email transaccional noreply@marduk.pro	Sistema (sin atención)	—
Dashboard de auditoría	Curador UTDI + admin	Continuo (alertas)
Audit pipeline automatizado	Sistema (cron 6h) + admin notificado	Automático
Pentest formal externo	Cédula 360 (proveedor)	Periódico
Reportes ejecutivos al CSJ	UTDI bajo demanda	1 click

Maloca cuenta con un Pentest formal externo realizado por Cédula 360 (2026-05-08) con 100/100 en ciberseguridad y 89/100 en accesibilidad.

El roadmap vigente registra 97% de cobertura del Miro original. Lo que queda pendiente es estructural:

Bloqueado por convenios (alcance externo · UTDI/CSJ):

• SSO con Entra ID / Active Directory
• Integración SIUGJ / SIERJU / SIGOBius

Completado en v2.11.0 → v2.11.2 (2026-05-19):

• ✅ UI por rol diferenciada (v2.11.0) — endpoint /api/me/dashboard.php + página /pages/inicio.php con 10 perfiles diferenciados, widgets condicionales por permisos y quick actions por rol (doc 48)
• ✅ Visor inline de archivos del repositorio (v2.11.1) — esta misma página: cualquier enlace a documentación técnica abre modal con tabs "Para no técnicos" (glosario 21 términos) y "Contenido" (Markdown XSS-safe o syntax highlighting nativo)
• ✅ Perfil personal transformado por rol (v2.11.2) — /pages/profile.php con hero gradient por color del rol, sparklines, heatmap GitHub-style de actividad 30d, donut de acciones 90d, "Tu impacto" con KPIs específicos por rol y cards balanceadas con fichas vacías contextuales

Roadmap interno post-v2.11.2 (alcance propio del equipo):

• Geolocalización IP offline (MaxMind GeoLite2) en audit
• VirusTotal real + análisis estático avanzado
• App móvil nativa (fuera del MVP, evaluable a futuro)

La API pública v1 y los endpoints REST internos quedan listos para abrirse apenas se firmen los convenios.