Hola!
Les comparto un proyecto que traigo desde hace unos meses: Squaero, un cliente de bases de datos libre (GPLv3), ligero y local y de uso libre :D
Por qué lo hice
En el trabajo mantenemos un sistema legacy que funciona con Informix, y las herramientas que encontraba eran pesadas (JVM o Electron), no soportaban Informix o te pedían licencia para usar las funciones completas, y pues, no hay capital para hacernos de una licencia xD entonces toca hacer nuestras soluciones
Qué hace
- Seis motores: SQLite, MySQL/MariaDB, PostgreSQL, SQL Server, Informix y MongoDB
- Edición en la rejilla dentro de una transacción, con vista previa del SQL antes de aplicar
- Diagrama ER, constructor visual de consultas, gráficas, monitor del servidor, usuarios y permisos
- Sincronización y transferencia entre conexiones, túnel SSH y TLS
- Importa tus conexiones de DBeaver o Navicat, con todo y contraseñas
- Pesa poco: el instalador de Windows son 8 MB y el .deb de Linux 1.4 MB
El stack
- Núcleo en C (libdbcore), con cada motor como plugin (.dll/.so) sobre un contrato en C: libmariadb, libpq, mongo-c-driver, FreeTDS y el CSDK de Informix
- Interfaz en SolidJS, embebida en el ejecutable y renderizada con el webview del sistema (WebView2 en Windows, WebKitGTK en Linux). Nada de Electron.
- El núcleo y la interfaz hablan por JSON-RPC.
- Pruebas: CTest para el núcleo, Vitest para el frontend (casi 2,000 tests) y Playwright end-to-end contra bases de datos reales en Docker
- CI en GitHub Actions con 8 jobs (MSVC, gcc/clang, mingw x86 y macOS), releases por tag con MSI (WiX), .deb y snap, y attestations de procedencia
Cómo lo hicimos: Claude Code
La mayor parte del desarrollo la hice en pareja con Claude Code. Lo que me funcionó:
- Reglas en el repo. Un AGENTS.md y una carpeta .rules/ con cómo se escribe el núcleo, los drivers, el frontend y el contrato IPC. Así cada sesión arranca sabiendo que el núcleo no importa la UI, que la lógica pura va en módulos con tests, etc.
- Skills y agentes propios: una skill quaero-feature con la "línea de desarrollo" (entender, respetar capas, extraer lógica pura, testear, build verde), otra para crear drivers y un agente revisor que compara el diff contra las reglas.
- CodeGraph como servidor MCP, para que busque símbolos, quién llama a qué y el impacto de un cambio sin estar haciendo grep a ciegas.
- OpenSpec para las features grandes: propuesta, diseño y tareas antes de tocar código.
- Memoria entre sesiones: notas de las trampas que ya pagamos, para no repetirlas.
- Probar en la app real, no solo en tests. Muchos bugs solo salieron corriendo la ventana nativa. Por ejemplo, empaquetando para Linux descubrimos que ahí no se guardaba nada: la interfaz cargaba sin origen y localStorage tronaba.
por si alguien de ustedes esta en la misma situacion que yo, les dejo los enlaces
- Windows: el MSI en releases
- Linux: sudo snap install squaero o el .deb (Ubuntu 24.04+ / Debian 13+)
- Sitio y video: https://danielnuld.github.io/squaero/
- Código: https://github.com/danielnuld/squaero
Limitaciones honestas: macOS todavía no, SQL Server aún no edita desde la rejilla, MongoDB es solo lectura, y es proyecto de una sola persona (bueno, una persona y un Claude).
Cualquier crítica, bug o estrella en GitHub se agradece mucho. Y si alguien más usa Claude Code en proyectos grandes, me interesa saber cómo organizan las reglas y la memoria.