Auditoría y entrega documental
Alcance y fuente de verdad
Fecha: 29 de octubre de 2026. Base inspeccionada: main, commit 0e6c41f4b2421b1c70c74c18c1c63c23625a2340. Rama documental: docs/professional-documentation.
Se enumeraron 659 archivos versionados: 263 en src, 41 en server, 10 en api, 32 en apps, 213 en tests, 56 documentos previos, cuatro scripts, un workflow y 21 archivos raíz. El inventario completo permite comprobar la cobertura del árbol; enumerar un archivo no equivale a ejecutar cada camino de código. La inspección semántica se repartió entre constructor, arquitectura, MCP, producto y operaciones, seguida de revisión cruzada.
Las fuentes principales fueron código, tipos, esquemas, configuración y tests; también se contrastaron documentos previos y los últimos commits. No se conectó una cuenta de usuario para probar producción ni se inspeccionaron credenciales o datos privados.
La migración de Firebase Functions del PR #93 está preparada en otra rama, pendiente de integración y despliegue. Su existencia no cambia la arquitectura vigente descrita aquí. El usuario pidió expresamente mantener ese despliegue pendiente.
Criterios de estado
- Implementada: existe una ruta funcional verificable en código; no certifica un despliegue externo.
- Parcialmente implementada: hay una parte funcional y faltan comportamientos necesarios para la capacidad completa descrita.
- Experimental: se limita a pruebas o condiciones especiales identificables.
- Planificada: una fuente explícita la plantea como trabajo futuro; no es una promesa comercial.
- No verificada: no hay evidencia suficiente para confirmar la capacidad o su operación externa.
La matriz de funciones contiene evidencia y límites. Un plan, tipo o componente visual aislado no acredita una función completa.
Entrega
Se creó una entrada general y navegación por audiencias, con guías del constructor, gestión de sitios, referencia MCP, arquitectura, configuración, pruebas, operación, contribución y seguridad. El índice enlaza cada área; mantenimiento documental define el proceso para conservarla vigente.
Se actualizaron README.md y ARCHITECTURE.md; la arquitectura anterior se conserva íntegra en archivo histórico, con aviso de contexto. Se conserva documentación técnica previa válida y se enlaza desde el índice. No se elimina una licencia ni se crea una licencia inventada: no se encontró una licencia general confirmada; se conservan los avisos de terceros.
CHANGELOG.md registra hitos del historial real y distingue PR de versión comercial. Se intentó actualizar la descripción y los temas de GitHub con la autorización del propietario; la integración devolvió HTTP 403: Resource not accessible by integration. Permanecen sin cambios. Propuesta: «Plataforma de creación visual y administración de sitios web con React, Firebase e integración MCP para agentes»; temas website-builder, visual-editor, react, typescript, firebase, mcp. Esta limitación no impide preparar la rama documental.
Hallazgos que afectan la lectura del producto
| Hallazgo | Tratamiento documental |
|---|---|
| README anterior usaba NexusBuilder y atribuía logística/pagos no acreditados | Nombre Wookcom; comercio descrito según implementación activa y límites. |
| Checkout prepara un mensaje de WhatsApp | No se presenta como cobro ni como pedido registrado automáticamente. |
| Estadísticas comerciales usan datos de pedidos registrados | No se presentan como liquidaciones bancarias verificadas. |
| Embudos registran visitas y leads; ventas/ingresos no completados | Se documenta el alcance parcial. |
| Dependencia Gemini sin consumidor encontrado | No se atribuye un generador IA integrado activo por esa dependencia. MCP se documenta separadamente. |
| Reglas Firestore y SDK Admin tienen límites diferentes | No se afirma protección global por Functions ni frontera exclusivamente de servidor. |
| CSP permisiva y secretos que dependen de configuración externa | Se registran, sin promesas de invulnerabilidad. |
| Registro estático de módulos, sin evidencia de microkernel extensible | Arquitectura por dominios; no se promete un mercado de plugins dinámicos. |
| Planes históricos y descripción administrativa antigua pueden quedar obsoletos | Se identifican y se enlaza documentación actual; no se toman como prueba de implementación. |
docs.wookcom.com propuesto |
No se configura ni se afirma la existencia de un centro público. |
Los límites adicionales de cursos, formularios, backups, colaboración y dominios están en limitaciones y en cada guía. Los errores potenciales de implementación se registran; no se corrigen en esta tarea documental.
Verificación
La validación documental comprueba destinos locales y anclas Markdown, nombres de comandos npm, cobertura de las 31 herramientas MCP y sus 17 operaciones, inventario de archivos, patrones de secretos en documentos nuevos y formato del diff. Resultado de la revisión: 47 documentos Markdown, 508 enlaces locales y anclas revisados, cero destinos o anclas rotos; 31/31 herramientas MCP documentadas, cero nombres inventados; 22 nombres de scripts documentados contrastados con los paquetes, sin comandos inexistentes; búsqueda de patrones de secretos sin hallazgos; git diff --check correcto. El archivo de inventario JSON se pudo leer y contiene los 659 destinos de la base. Una revisión independiente contrastó arquitectura, permisos, formularios, consola y contratos MCP contra sus fuentes. No se agregaron dependencias para validar documentación.
No se ejecutan nuevamente suites de producto ni despliegues: no hay cambios de lógica, interfaz, API, esquemas, dependencias o configuración. La referencia a un test indica evidencia de comportamiento esperado; no implica que ese test se haya ejecutado durante esta entrega. No se certifican DNS/TLS, clientes IA externos, pagos, envío logístico, IAM, reglas efectivamente desplegadas ni recuperación de datos en producción.
Mantenimiento recomendado
- Exigir cambios documentales junto con cada cambio de comportamiento.
- Actualizar el estado y ejemplos MCP al cambiar esquemas, herramientas o permisos.
- Revisar instrucciones de interfaz al reorganizar paneles.
- Mantener el contexto histórico de planes e informes.
- Incorporar validación documental a CI en una tarea posterior autorizada, sin credenciales ni despliegue.
- Diseñar el portal público después de revisar contenido, políticas y disponibilidad; reutilizar el Markdown actual.