Calidad de código e infraestructura
Estado verificable, seguridad local y plan de corrección.
← Volver a arquitecturaDictamen
La base de 7.11.0 es comprobable y modular en el código fuente: 644 pruebas generales y 71 de navegador pasan en esta revisión; npm run build reconstruye el backend sin diferencias. Persisten límites de seguridad y recuperación que deben tratarse como trabajo pendiente. No se ha demostrado una intrusión remota ni se ha medido cobertura de líneas.
1. Alcance y método
Se revisaron zerochat.html, js/, css/, py/, zerochat.py, sw.js, tests/, scripts/ y flujos CI. Se compararon las afirmaciones del informe 7.8.0 con código y pruebas actuales. Es una inspección estática con pruebas locales; no incluye pentest, proveedores reales, todos los navegadores ni evaluación de carga.
Estado examinado: rama dev en versión 7.11.0. Las referencias de archivo enlazan al código revisado.
2. Validación ejecutada
| Comprobación | Resultado | Alcance |
|---|---|---|
npm test | 644/644, 0 fallos | Suite configurada por el proyecto, con lógica, integración, arquitectura, infraestructura y navegador. |
npm run test:browser | 71/71, 0 fallos | Chromium local y escenarios Playwright; varios casos vigilan errores de página y consola. |
npm run build | Correcto | Orama y backend ensamblado. Sin diferencias generadas en archivos de producto. |
Los tests de proveedores usan simulaciones en buena parte; no acreditan disponibilidad de APIs externas. No se midió rendimiento, cobertura de ramas, accesibilidad con lector de pantalla ni fiabilidad offline de extremo a extremo.
3. Arquitectura observada
La web se sirve como HTML/CSS/JS estático; ChatState concentra el estado de conversación, ZeroChatDB canaliza IndexedDB, BaseProviderAdapter normaliza proveedores y el contrato de herramientas define registro y vista. El backend se ensambla desde py/*.py; zz-main.py queda al final. El wheel está diseñado para contener solo el ejecutable Python, según pyproject.toml y la prueba de empaquetado; el wheel no se reconstruyó aquí.
La concentración de código sigue siendo un coste de mantenimiento: js/app.js supera 2.100 líneas, js/file-parser.js 2.000 y js/agent-core.js 1.600. El tamaño por sí solo no demuestra defecto; los cambios deben seguir separándose por responsabilidad y contar con regresiones específicas.
4. Hallazgos abiertos
| ID / prioridad | Evidencia e impacto | Corrección y prueba de aceptación |
|---|---|---|
| F2 · Alta | ee-mcp.py valida edit_file.mode como texto de hasta 32 caracteres, pero no el enum anunciado en dd-tools.py. En edit_file, cualquier modo desconocido con content cae en la rama de escritura completa. Una llamada RPC autenticada puede sobrescribir un archivo por error de modo. | Rechazar modos fuera de surgical|write|append|replace_chunk antes de tocar el archivo, también en la función Python. Probar por HTTP que un modo inválido deja bytes y metadatos intactos. |
| Q1 · Alta | profile-backup.js usa un SHA-256 directo como material de contraseña y guarda ese valor reutilizable hasta 24 horas en localStorage. Una copia cifrada con la clave pública predeterminada ofrece confidencialidad limitada; un script con acceso al mismo origen puede recuperar el material temporal. | Derivar la clave con KDF y sal únicos, versionar el formato y migrar copias existentes; reducir o eliminar la caché persistente. Probar descifrado heredado, contraseña errónea, expiración y recuperación entre pestañas. |
| Q2 · Media | cc-environment.py conserva el token del servidor por día en ~/zerochat/config/token.json, sin fijar modo 0600 al crearlo. La seguridad del archivo depende del umask; un reinicio el mismo día reutiliza el token. | Crear con permisos exclusivos, verificar permisos de archivos existentes y decidir si el token debe rotar por arranque. Probar modo de archivo con umask permisivo y rechazo del token anterior tras rotación. |
| Q3 · Media | sw.js usa Promise.allSettled y omite fallos de descarga durante instalación. Puede activarse una caché incompleta aunque los tests de rutas publicados pasen. | Definir activos mínimos obligatorios y fallar o reintentar la instalación si faltan. Probar instalación con un recurso crítico caído y recarga offline bajo /zerochat/. |
| Q4 · Media | tool-security.js evalúa reglas R/W y permisos en el navegador. ff-server.py autentica las llamadas RPC pero no recibe ni aplica esas políticas. Quien tenga un token válido puede invocar directamente herramientas locales con privilegios del usuario. | Documentar y, si se requiere una frontera resistente a clientes alterados, validar permisos en el backend con política independiente. Probar petición autenticada directa fuera de la carpeta autorizada y revocación. |
Q4 describe una frontera arquitectónica, no una explotación sin token. La ejecución shell y MCP no queda aislada por el venv: este aísla dependencias Python, no permisos del sistema.
5. Hallazgos anteriores y riesgo residual
De los F1–F4 del informe de 7.8.0, F1, F3 y F4 ya no deben publicarse como fallos abiertos. F2 sigue abierto, según la evidencia anterior. Las pruebas de permisos incluyen composición de prefijos y carpetas, rutas relativas y alias de shell. read_file lee con presupuesto UTF-8 y edit_file declara un enum de modos que el validador RPC no aplica. La prueba de Service Worker ejecuta su handler para la ruta publicada. Quedan límites de cobertura: la prueba de precaché no simula caída de red.
Las superficies innerHTML, Markdown, tarjetas de herramientas y URLs siguen requiriendo inspección al modificarse. Los tests actuales cubren sanitización de utilidades y casos de UI, pero una búsqueda textual de innerHTML no prueba ni descarta XSS.
6. Higiene de código y fronteras
Se buscaron llamadas a diálogos nativos, propiedades de herramientas obsoletas, variables de estado fuera de ChatState, asignaciones a innerHTML, registros de eventos y claves de traducción. Los contratos de arquitectura y las pruebas actuales cubren diálogos, iconos, herramienta declarativa, estado y sanitización en rutas concretas. No se declaró código muerto solo por ausencia de una referencia estática: los módulos UMD, registros dinámicos y cargas HTML requieren confirmar uso en ejecución. Tampoco se halló una duplicación funcional suficientemente demostrada para recomendar una extracción general.
La revisión de HTML exige especial atención a resultados MCP, títulos de documentos y tarjetas del agente. ChatUtils ofrece primitivas de texto y sanitización; Markdown mantiene una frontera propia. Para cada cambio de presentación con datos externos, conviene una prueba de inyección con texto, URL y atributo malicioso.
7. Orden de trabajo
- Corregir F2 y añadir regresión HTTP.
- Revisar el diseño de cifrado y caché de Q1 con migración compatible.
- Endurecer creación y rotación del token Q2.
- Decidir explícitamente el modelo de confianza de Q4 y añadir una prueba de llamada RPC directa.
- Hacer verificable la instalación offline Q3 y probar fallos parciales.
- Mantener suites de navegador y empaquetado en CI para cada promoción.
No se recomienda una refactorización general a partir de métricas de tamaño. Cada corrección exige una prueba que reproduzca el comportamiento concreto.