MicelClaw OS

Un lugar para relacionar el trabajo

Notas, archivos, correo, calendario y tareas suelen vivir en aplicaciones distintas. MicelClaw OS plantea reunir esa información en un entorno autoalojado, con una interfaz común y agentes de IA capaces de trabajar sobre ella. El proyecto une organización de datos, diseño de interfaces e integración de servicios.

La palabra «OS» expresa esa ambición de entorno completo de trabajo. La arquitectura documentada se apoya en un núcleo de servicios, una base de datos y una aplicación web. OpenClaw aporta la ejecución de agentes; MicelClaw desarrolla una capa de producto alrededor de ese componente.

El proyecto cuenta con una web propia, documentación pública y un cuaderno técnico en DEV. El portfolio presenta mi trabajo sobre el producto; esos espacios permiten profundizar en sus funciones y evolución.

Una interfaz para distintas escalas de información

La navegación reúne tareas habituales en módulos reconocibles. Las capturas publicadas permiten recorrer esa estructura: una nota y sus relaciones, una agenda mensual y un archivo organizado en carpetas. Se han seleccionado vistas distintas para explicar decisiones de interfaz, no repetir pantallas casi iguales.

Calendario: el mes da una lectura global; el color distingue fuentes dentro de la misma superficie. Captura de la web oficial del proyecto.

Drive: la selección y las acciones conviven con un panel de información relacionada. Captura de la web oficial del proyecto.

La dirección visual toma como referencia el tema Lucid de Dash: fondos con un matiz lavanda, paneles escalonados, separadores finos y un color propio para cada módulo. Esta jerarquía ayuda a distinguir navegación, contenido y contexto sin multiplicar interfaces independientes.

Aportación y alcance

Es un proyecto personal de diseño y desarrollo de herramientas. El caso se centra en la definición del producto y en la relación entre sus piezas: cómo se representa la información, cómo se consulta y qué puede hacer un agente sobre ella. Los componentes externos conservan su identidad y atribución; en particular, OpenClaw no se presenta como desarrollo propio.

La revisión del código y la documentación confirma un trabajo dividido en varios repositorios: Core, la interfaz Dash, una API cloud independiente y clientes complementarios. El alcance exacto de la contribución personal en cada módulo sigue pendiente de una ficha de autoría.

Tres capas que deben entenderse entre sí

Esquema conceptual elaborado para este caso a partir de la documentación del proyecto.

Interfaz. Dash organiza módulos como notas, calendario, archivos, contactos, proyectos, inventario y finanzas. Su código utiliza React y Vite. La agrupación por tareas permite presentar una superficie reconocible aunque detrás haya servicios distintos.

Núcleo de datos y servicios. Core reúne la API y las reglas de cada dominio. La documentación describe Fastify, PostgreSQL y Drizzle, junto a mecanismos de búsqueda, sincronización, permisos y relaciones entre registros. Una nota o una tarjeta de trabajo no es solamente texto visible: forma parte de un modelo de información.

Agentes y herramientas. La integración con OpenClaw pasa por una fachada MCP: un catálogo de operaciones que los agentes pueden solicitar. Esta separación permite definir las capacidades en el núcleo y representarlas en la interfaz, en lugar de confiar la lógica del producto a una conversación aislada.

Una decisión concreta: el tablero como unidad de trabajo

El módulo Projects ofrece un ejemplo de cómo una decisión de datos afecta a la experiencia. Su documentación de implementación describe una estructura tablero → columnas → tarjetas. El tablero es la unidad que se organiza, comparte y archiva. Las tarjetas pueden relacionarse con otras entidades del sistema.

Esta estructura evita añadir un nivel de «proyecto» sin una función clara. También distingue el trabajo del usuario de la coordinación interna entre agentes, que tiene su propio espacio. La decisión no es únicamente de nomenclatura: determina qué se guarda, qué se comparte y qué debe explicar la interfaz.

Diseñar, contrastar y mantener

La documentación del repositorio diferencia visión de producto, decisiones de arquitectura, módulos implementados y trabajo pendiente. Su mapa de fuentes señala incluso propuestas retiradas o sustituidas. Este método permite contrastar una idea con el estado del código antes de convertirla en una promesa de producto.

La misma cautela se aplica al caso del portfolio. Se ha revisado documentación y estructura de código el 13 de octubre de 2026; no se ha arrancado el producto ni ejecutado aquí una prueba completa de sus flujos. El resultado mostrado es un sistema en desarrollo con arquitectura y módulos identificables, sin cifras de usuarios, rendimiento o ahorro de tiempo no acreditadas.

Decisiones contadas durante el desarrollo

La publicación técnica del proyecto amplía tres aspectos especialmente relacionados con este caso:

• La fachada MCP: cómo los agentes se comunican con el núcleo: una traducción de herramientas hacia la API existente, con el mismo recorrido de permisos.
• Un grafo de conocimiento construido sobre PostgreSQL: el modelo de relaciones como parte del producto. El índice completo está disponible en DEV.
• Archivos y las preguntas que una carpeta no responde: el contexto que acompaña a la organización del archivo.

Pendiente [MC-01]: documentar un flujo completo con capturas actuales, desde la creación de información hasta su consulta mediante un agente. Las vistas públicas ya incorporadas corresponden a la presentación del producto.

Pendiente [MC-02]: concretar la aportación personal por módulos y los componentes reutilizados. La web, la documentación y los canales oficiales ya están enlazados.

El interés por el autoalojamiento también aparece en el NAS y servidor doméstico: organizar infraestructura para que las herramientas tengan un soporte comprensible y mantenible.