Qué es
Claude en tu carpeta del VPS
Cuando trabajas: corre en el VPS, en tu carpeta aislada. Tú diriges, él programa.
el VPS
Claude del Hub
Resume, clasifica emails, levanta Odoo y testea. También en el VPS. Nunca mergea.
Empieza en el D6, pero pensado para toda la empresa
El Hub se organiza por departamentos. Cada uno tiene sus devs, sus clientes, su memoria y sus estándares. Arrancamos solo con el D6 (ERP / Odoo); añadir otro es una partición más, sin rehacer nada.
Empresa
└── Departamentos
├── D6 · ERP (Odoo) # empezamos aquí
│ ├── devs # sus cuentas
│ ├── clientes # JMC, …
│ ├── memoria # propia del D6
│ └── estándares # Odoo / OCA
├── D? · (futuro) # otro stack, otros devs
└── …
/opt/hub/departamentos/D6/ ├── git/ · repos/ · memoria/ · staging/ └── (mañana) …/D?/ # una partición más Forgejo: una organización por departamento org D6 → los repos de sus clientes
Cada departamento, su mundo
Los devs de un departamento no ven lo de otro. Dentro del D6, todos ven qué hace el resto.
Empresa + departamento
Reglas comunes de la empresa + las propias de cada uno. El D6 usa las de Odoo/OCA.
Añadir uno = una partición
Un departamento nuevo es una carpeta y una org de Forgejo más. Nada del D6 se rehace.
Las capacidades y su "hecho"
Cada capacidad tiene un criterio medible de cuándo está terminada — sin tecnicismos, en qué se nota.
Memoria compartida
Cualquier dev abre un cliente y Claude ya sabe su contexto, lo último que hizo cualquiera y las tareas abiertas.
Presencia en vivo
Ver en un sitio quién trabaja ahora, en qué cliente y rama. Si dos coinciden, ambos reciben aviso.
Emails → tareas
Por ahora cada dev pega el email de su cliente en su propio Claude; en minutos hay una tarea clasificada en el cliente correcto.
Testeo automático (QA)
El Hub levanta el Odoo del cliente, corre los tests y prueba en navegador — la red de seguridad.
Claude del Hub bajo demanda
Te conectas al VPS y le encargas ("analiza el issue #12"); trabaja en ramas hub/* y entrega una propuesta.
Onboarding de un dev
Un comando deja la máquina lista: VPN, repos, hooks e identidad.
El mapa, de un vistazo
Para empezar, la conexión al VPS es simple: acceso directo (SSH) para quien quiera ir al grano, o a través del Claude de cada dev. El método definitivo se decide más adelante.
Los devs — su ordenador es solo un terminal para conectarse
◑ ERP Hub — VPS 16 GB
self-hostedHacia fuera
Qué carpetas hay en cada lado
El ordenador del dev es solo un terminal para conectarse. Dentro del VPS, cada empleado tiene su cuenta y su carpeta privada; el cerebro es compartido.
# En el portátil NO vive el código. # Solo un cliente para conectarse: $ erp → conecta al VPS (usuario + contraseña) → abre Claude en tu carpeta del VPS # Sus cosas personales las hace aparte, # en su propia máquina — fuera del ERP.
/home/juan/erp/jmc # privado de Juan (solo él) /home/pedro/erp/jmc # privado de Pedro · mismo cliente /home/maria/erp/cliente-x /opt/hub/ # cerebro COMPARTIDO (todos leen) ├── memoria/ # contexto · sesiones · tareas · emails ├── codegraph/ · kg/ # grafos de código y conocimiento ├── staging/ # Odoo doodba on-demand └── agentbrowser/ # pruebas
Un responsable lo da de alta en el VPS · el dev entra con su usuario y contraseña
Un responsable (con acceso admin) se conecta al VPS y da de alta al usuario con su email y su contraseña. Cuando ese dev arranca en su ordenador, inicia sesión con esas credenciales — y con eso queda todo montado.
$ hub-nuevo-dev Usuario: juan Email: juan@labelgrup.com Contraseña: 7fK2-p9Qr (o generar) ✅ Dev creado: juan (juan@labelgrup.com) Clientes: — # hub-asignar juan jmc # Pásale las credenciales por un canal seguro.
$ erp ── ERP Hub ─────────────────────── Inicia sesión con tu usuario y contraseña Usuario: juan Contraseña: •••••••• ──────────────────────────────────── ✅ Bienvenido, Juan — ya estás dentro Proyectos, hooks y contexto: listos. Abriendo Claude en ~/erp/ …
Un responsable, desde el VPS
Alguien con acceso admin se conecta al VPS y da de alta al usuario con su email y su contraseña. Queda registrado en el cerebro. Nadie se auto-registra.
Usuario + contraseña
La primera vez, el dev teclea sus credenciales. El instalador valida contra el VPS y deja todo montado sin que toque nada más.
La contraseña, solo una vez
En ese primer login se instala una clave en su máquina. A partir de ahí conecta sin contraseña y de forma segura — él solo recuerda su usuario y su pass.
Dar de baja a alguien es igual de simple: un comando en el VPS borra su acceso al instante. Y añadir al dev nº 4, 5, 6… es exactamente el mismo hub-nuevo-dev — por eso el equipo se abre a más gente sin rehacer nada.
El VPS sabe dónde tiene cada uno sus proyectos
No todos guardan los proyectos en la misma ruta. El cerebro registra, por dev, en qué carpeta local vive cada cliente — para saber siempre dónde está todo.
--- dev: juan maquina: portatil-juan clientes: jmc: ~/erp/jmc cliente-x: ~/erp/cliente-x ultima_conexion: 2026-07-16 09:05 --- # Juan — dev del equipo ERP Skills y estándares globales sincronizados ✅
--- dev: pedro maquina: mac-pedro clientes: jmc: /Users/pedro/dev/jmc otro: /Users/pedro/dev/otro ultima_conexion: 2026-07-16 09:31 ---
Se registra en el alta del dev y se actualiza solo cuando clona un proyecto nuevo. Así el cerebro —y su Claude— saben exactamente en qué ruta de cada máquina vive cada cliente, aunque cada uno lo tenga en un sitio distinto.
Cómo el dev sabe que está conectado
No hay ritual de conexión: la VPN está siempre arriba y el cerebro se conecta solo al abrir Claude. Estas dos piezas —baratas— hacen que el dev lo vea y confíe desde el primer segundo.
Dinámico, bajo demanda
El VPS expone un servidor MCP. El Claude del dev consulta y escribe en el cerebro en el momento exacto en que hace falta (contexto del cliente, presencia, crear tarea). Es lo mismo que ya hace CodeGraph.
Automático, garantizado
Aunque Claude no llame a nada, los hooks capturan siempre lo esencial: los eventos de presencia y el cierre de bloques. La red de seguridad para que nada dependa de que "se acuerde".
$ claude ── ERP Hub ───────────────────────────── ✅ Conectado al cerebro (VPS) 12 clientes · Pedro y María activos ahora 3 tareas tuyas abiertas en JMC ───────────────────────────────────────── # si el VPS no responde: ⚠️ Sin conexión al cerebro No se llega al VPS → revisa tu conexión (sigues trabajando; se sincroniza al volver)
$ erp ▸ Conexión al VPS…… ✅ el VPS responde ▸ Cerebro ERP (MCP)… ✅ conectado ▸ Repo de memoria…… ✅ al día (pull ok) ▸ Identidad……… Juan · JMC, Cliente-X Todo listo — abriendo Claude en ~/erp/ …
Dos modos: el trabajo del equipo y lo tuyo
El dev tiene libertad total para sus cosas. Solo el trabajo dentro de su zona ERP entra en el cerebro compartido — todo lo demás es privado.
El trabajo del equipo
Abre Claude en su carpeta ERP. Conectado al VPS: contexto inyectado, acciones capturadas, tareas y resúmenes compartidos con el equipo.
Lo suyo, privado
Abre Claude normal en cualquier otra carpeta. Nada se conecta al VPS, nada se captura, nada se comparte. Sus experimentos y proyectos son suyos.
La maquinaria vive pegada a la carpeta ERP
Los hooks y el servidor MCP del VPS se instalan en la config de la carpeta ~/erp/, no en la global de Claude. Así solo se activan ahí dentro. Y como doble seguro, los propios hooks comprueban la ruta: fuera de la zona ERP, no hacen nada.
Cada uno en su cuenta — pero todos saben qué hace el resto
Parece una contradicción y no lo es: se comparte el conocimiento, no los archivos.
Aislado
Cada dev = una cuenta separada, con su carpeta privada. No puede abrir los proyectos de otro. Su código y sus ramas son suyos y solo suyos.
Compartido
Toda la info se guarda en el cerebro común: presencia, actividad, resúmenes, tareas. Todos ven qué hace y qué ha hecho el resto — como información, no abriendo archivos ajenos.
Por dentro: cómo se organiza en el VPS
Tres niveles de copia del código, más un cerebro y un clon de referencia fuera de los usuarios. Eso resuelve el aislamiento, el seguimiento y las pruebas de varios devs a la vez.
/opt/hub/ # ZONA DEL HUB — fuera de los usuarios ├── git/jmc.git # repo "origin" (bare): TODOS pushean aquí ├── repos/jmc # clon de REFERENCIA · aquí corre el cron git pull ├── memoria/ # cerebro compartido (todos leen) │ ├── equipo/estado.md # presencia en vivo │ └── clientes/jmc/ actividad.md · sesiones/ · tareas/ ├── staging/ # Odoo doodba on-demand └── ports.registry # qué puerto usa cada dev /home/juan/ # cuenta aislada (permisos 700) ├── erp/jmc/ # COPIA DE TRABAJO de Juan (origin = /opt/hub/git/jmc.git) └── .claude/ # sus hooks + transcripts (privados) /home/pedro/ erp/jmc … # copia de Pedro · mismo cliente, sin choque
Todo lo que hace cada uno, guardado
Cada cuenta corre Claude con los hooks. El observer apunta cada acción al cerebro compartido, etiquetada con el usuario y el cliente. Escritura local en el mismo disco: instantánea.
Saber qué hace cada uno
Al hacer push, el commit va al bare /opt/hub/git/. El cron hace git pull en el clon de referencia, detecta commits nuevos de cualquiera y los apunta en actividad.md + reindexar CodeGraph.
Levantar el web, varios a la vez
Un comando busca un puerto libre y arranca el Odoo de la copia de ese dev, lo anota en ports.registry y da la URL. O un rango por dev (Juan 8069–79, Pedro 8080–89…). Nunca chocan.
Pruebas concurrentes
Cada dev lanza su propio Chromium headless contra su Odoo (su puerto). Procesos independientes y aislados. Límite = RAM del VPS; para pocos devs, de sobra. Playwright deja capturas, sin pantalla.
Su propio clon, sus ramas, su PR
Cada dev tiene su propio clon del proyecto —aunque sea el mismo cliente que otro—. Todos comparten un único origin en el VPS; trabajan aislados y se sincronizan por ahí.
┌──────────── Forgejo (VPS) ────────────┐ │ origin · PRs · issues · usuarios │ └───▲───────────────▲───────────────▲────┘ push │ │ │ /home/juan/erp/jmc /home/pedro/erp/jmc /home/maria/erp/… clon de Juan clon de Pedro clon de María rama jmc/feat-x rama jmc/fix-stock (mismo proyecto, clones distintos)
Su clon
Cada dev tiene su propia copia del proyecto en su carpeta, con el origin apuntando a Forgejo. Aunque dos trabajen en JMC, son dos clones separados.
Su rama
Claude crea una rama por tarea (jmc/feat-descuento) en el clon del dev. Nadie pisa a nadie.
Commit + push
Se commitea y se hace push de la rama al origin de Forgejo. Ahí aparece para todos, y el cron la registra en la actividad del cliente.
Su PR
El dev abre la PR en Forgejo (jmc/feat-descuento → develop-jmc). El Claude del Hub la testea y deja el veredicto; mergea un humano.
Estándares, skills y agentes
La manera de trabajar no se le explica a cada dev: se define una vez y le llega sola a su Claude. Igual que en la Pi, pero compartido por todo el equipo.
Cuatro capas de reglas — cada una vive donde le toca
| Capa | Ejemplos | Dónde vive |
|---|---|---|
| Global todo el equipo | Commits en inglés · rama por tarea · no tocar PROD · black/ruff/pylint-odoo | VPS · biblioteca global |
| Por stack | "Odoo → convenciones OCA + estas librerías" | VPS · según el stack |
| Por negocio | "JMC factura a 60 días · no tocar la secuencia de facturas" | VPS · contexto del cliente |
| Por proyecto técnico | CLAUDE.md del repo · skill "añadir campo a la factura" · agente "jmc-tester" | En el git del proyecto |
Lo del proyecto viene con el código
El CLAUDE.md, los skills y los agentes dentro del repo llegan solos al clonarlo. Los tiene el dev y también el Claude del VPS. Cero esfuerzo.
Lo global se inyecta al arrancar
El hook injector hace pull del VPS y mete en contexto solo lo que aplica: global + stack del proyecto + negocio del cliente. Como ya haces en la Pi.
Y funciona en los dos sentidos: cuando un skill de un proyecto resulta útil para todos, se promociona a global — pasa a la biblioteca del VPS y desde entonces lo tiene el equipo entero. El maletín común crece con lo que aporta cada uno.
Contexto real, no abstracto
Ejemplos con contenido real de cómo se ve la ficha de un cliente, la presencia del equipo y un email ya convertido en tareas.
--- cliente: jmc dev_asignado: juan odoo_version: "17.0" --- # JMC S.L. Distribuidora de material de oficina, ~40 empleados. Contacto: Marta (admin). ## Siempre tener en cuenta - No tocar la secuencia de facturas (AEAT). - Aprobación de pedidos > 5.000 €. - A producción solo los viernes por la mañana.
--- dev: juan cliente: jmc rama: jmc/feat-descuento tarea: "#48 descuento no sale a crédito" --- # Bloque de trabajo — Juan en JMC ## Qué se hizo - Bug en account_move.py: condición de pago demasiado estricta. Corregido. - Añadido test test_descuento_credito. ## Estado — rama lista, pendiente QA. NO mergeado.
equipo/estado.md — presencia en vivo (TTL 30 min)
| Dev | Cliente | Rama | Última acción | Desde |
|---|---|---|---|---|
| Juan | JMC | jmc/feat-descuento | edit invoice.py | 09:05 |
| Pedro | JMC | jmc/fix-stock | run tests | 09:31 |
| María | Cliente-X | x/portal-login | edit portal.js | 08:50 |
Un email de JMC, de punta a punta
Sigue una petición real desde que llega hasta que se aprueba, viendo qué cuerpo actúa en cada paso.
Llega el email local
Marta escribe a Juan. Él lo pega a mano en su Claude, desde su propio ordenador: "tengo este email de JMC…". Su Claude lo interpreta al vuelo. (Sin buzón automático por ahora.)
Se parte en tareas local
Detecta JMC y separa dos cosas: un bug (descuento a crédito) y una mejora (exportar a Excel). Crea los issues #48 y #49 en el centro, no en el portátil.
Juan trabaja el bug local
Al decir "vamos con el bug de JMC", el hook le inyecta el contexto del cliente y lo que hizo Pedro. Claude corrige en la copia local, en jmc/feat-descuento.
Cambia de cliente → se guarda solo hub
Juan salta al Cliente-X sin cerrar nada. El cambio de cliente cierra el bloque: el Hub lo resume desde el flujo de eventos y lo guarda en sesiones/.
El Hub testea hub
Te conectas al VPS y le dices "prueba la rama de descuento": levanta el Odoo de JMC (doodba), corre los tests, factura a crédito con Playwright y responde ✅ 12 tests OK, descuento correcto (captura).
Un humano aprueba
Un dev revisa y mergea. El Hub nunca mergea ni toca producción.
El cerebro aprende sobre la marcha — y no duplica
No hay que dar de alta nada antes de empezar. En cuanto algo aparece, el cerebro lo registra solo en la carpeta del cliente con todo lo que necesita. Y si ya existía, avisa en vez de duplicar.
Se registra al tocarlo
Un dev empieza con "Bodegas Rivas", que no existe. Su Claude crea la ficha esqueleto, empieza a registrar la actividad, y pide dos líneas de contexto que solo sabe un humano.
Genera todo en el centro
Le pasas el email a mano. El cerebro genera en la carpeta del cliente todo lo que necesita: guarda el email, lo clasifica, crea la tarea con el texto citado y la prioridad. Sin que muevas nada más.
Avisa, no duplica
Si otra persona pasa el mismo email, el cerebro ve que ya existe la tarea y quién la lleva — y te lo dice, en vez de crear un duplicado.
$ "tengo este email de JMC: no sale el descuento…" ⚠️ Esto ya está registrado Tarea #48 · "descuento no sale a crédito" (JMC) La lleva Juan · rama jmc/feat-descuento · desde 09:05 No creo un duplicado. ¿Quieres verla o añadir algo?
Puede hacerlo porque todo vive en el centro: las tareas y la presencia. Antes de crear nada, el cerebro mira si ya existe una tarea para eso en ese cliente y si alguien está en ella. Los dos únicos límites: no puede probar código que no esté subido al remoto, ni inventar el contexto de un cliente nuevo — eso lo teclea un humano (dos líneas).
Dos grafos, unidos por el módulo
El grafo del código y el grafo del conocimiento del departamento, conectados: desde una tarea saltas directo al código que la resuelve.
Grafo de código
La estructura del código de los 10 clientes. Ya lo usas.
- "¿Dónde se calcula el descuento en JMC?" → _compute_amount()
- Quién llama a qué, sin grep.
- Se refresca con codegraph sync tras cada pull.
Grafo de conocimiento
Las entidades del departamento y sus relaciones, sobre los mismos markdown.
- "¿Qué módulos toca más Pedro?"
- "Este email, ¿en qué acabó?" → Tarea → Commit
- "¿Qué tareas abiertas tiene JMC?"
El nexo es el módulo: el nodo jmc_facturacion del grafo de conocimiento apunta a su subgrafo en CodeGraph. Así, desde "tarea #48 sobre facturación de JMC" saltas al código real sin buscar a mano.
Cinco vigilantes, cada uno una cosa
Mismo patrón que tu scheduler actual con claude -p. Ninguno depende de que un dev haga nada.
| Bot | Cada | Qué hace |
|---|---|---|
| fetch-commits | 10–15 min | git fetch de los 10 repos → apunta commits en actividad.md → refresca CodeGraph y el grafo. |
| email-inbox (futuro) | 5–15 min | Automatiza el buzón tareas@. Al principio no hace falta: los devs pasan los emails a mano desde su Claude. |
| work-blocks | 5 min | Detecta bloques cerrados (cambio de cliente / inactividad / fin de día) → resume → guarda la sesión. |
| hub-queue | 2 min | Lee hub/cola.md → ejecuta encargos del Claude del VPS (testeo, análisis) → informe. |
| digest-diario | 09:00 | Resumen del día anterior por dev/cliente → queda en el VPS, lo ves al conectarte. |
📊 Equipo ERP — 16/07 JMC: 4 commits (Juan 3, Pedro 1) · issue #48 en QA ✅ · 2 tareas nuevas por email Cliente-X: 2 commits (María) · portal-login en progreso 🔴 Pendiente aprobación: merge de jmc/feat-descuento
Hoja de ruta por fases
Cada fase entrega valor por sí sola. Con las tres primeras ya tienes el corazón funcionando.
Cimientos
VPS + WireGuard + repos + secretos cifrados + script de onboarding.
Visibilidad
Cron que registra commits por cliente + digest que ves al conectarte.
Memoria + presencia
Tus hooks en modo equipo: contexto al abrir, resumen por bloques.
Emails → tareas
Buzón + clasificación automática → issue + borrador de respuesta.
El cuarto trabajador
Claude del Hub + Odoo staging (doodba) + QA con Playwright.
Extras
Grafo semántico completo, Plane, dashboard — cuando duelan, no antes.
Las dos vías, cara a cara
Estás viendo la Opción 2 (todo en el VPS) — cambia arriba a la Opción 1 para verla completa. El cerebro, la memoria y las tareas son iguales en las dos; lo único que cambia es dónde vive el código y dónde corre Claude.
Cara a cara
| Dimensión | Opción 1 · local | Opción 2 · todo en el VPS |
|---|---|---|
| Dónde vive el código | Portátil de cada dev | En el VPS, carpeta por empleado |
| Dónde corre Claude | En el portátil | En el VPS |
| Onboarding | Instala repos, hooks, config local | más simple user+pass y a trabajar |
| Entorno | Distinto en cada máquina | idéntico lo monta el admin |
| Aislamiento entre devs | Natural (cada uno su máquina) | cuentas separadas nadie ve el código de otro |
| Trabajar sin conexión | sí | no |
| Si el VPS se cae | Cada uno sigue en su local | equipo parado (backup obligatorio) |
| Recursos del VPS | Ligeros (solo cerebro) | Altos (N Claudes + N Odoos) |
| Se parece a… | — | Cómo Emilio ya usa la Pi |
Lo que tienes que confirmar
Solo estas bloquean. En tres ya hay recomendación clara; una es grande.
¿Dónde vive el código de los clientes?
GitHub privado + copias espejo, o Forgejo en el VPS. Lo más caro de revertir.
Recomendación GitHub — pero revisa antes si algún contrato prohíbe la nube. Si alguno exige on-premise → Forgejo.
El VPS
Proveedor y tamaño. Lo monta el equipo de sistemas.
Recomendación OVH nuevo, 16 GB. Nunca el VPS2 (PROD de thetraktor).
Suscripciones Claude
Cuántas y de qué nivel. Es el coste dominante.
Recomendación 3× Max (devs) + 1 para el Hub. Evaluar plan Team.
Buzón de emails
No bloquea el arranque: por ahora cada dev pasa los emails a mano desde su ordenador. El buzón automático tareas@… queda para cuando queráis automatizarlo.
Sin prisa el dominio se decide al llegar a F3.
Las credenciales de 10 clientes. Hoy viven en texto plano en los markdown. El Hub concentraría los accesos de 10 empresas, así que sops + age desde el día 0 es innegociable — cifradas dentro del repo, una clave por persona.
Con qué se monta — y qué reaprovecha
Casi todo el software es open-source o ya lo tienes montado. El único coste recurrente real son las suscripciones de Claude.
| Pieza | Herramienta | Rol | ¿Ya lo tienes? |
|---|---|---|---|
| Conexión al VPS | SSH (por ahora) | Acceso directo o vía el Claude del dev · método final a decidir | — |
| Memoria | repo git de markdown | Fuente de verdad, versionada | ✅ tu sistema de memoria |
| Grafo de código | CodeGraph | Estructura del código | ✅ ya en 5 repos |
| Grafo de conocimiento | Basic Memory | Entidades y relaciones sobre los MD | nuevo |
| Tareas | issues del forge | Tarea ↔ commit, en el centro | ✅ gh CLI |
| Presencia + resúmenes | hooks + claude -p | Quién hace qué, sin cerrar sesión | ✅ injector/observer |
| Email → tarea | IMAP + Haiku | Clasificación automática | ✅ patrón soporte email |
| Testeo | doodba + Playwright | Levanta Odoo y prueba | ✅ Playwright |
| Secretos | sops + age | Credenciales cifradas | nuevo · necesario |
| Cron | scheduler propio | Los 5 bots | ✅ tu scheduler |