Cómo trabajamos — el método del equipo explicado para cualquiera

Cómo trabajamos — el método del equipo explicado para cualquiera

Para quién es esta página: los tres del equipo (Edu, Dani, Txell) y quien se incorpore después. Explica el ciclo completo de trabajo sin tecnicismos; cada sección enlaza a la guía técnica correspondiente para quien quiera profundizar. Creada en la auditoría s185 (02-07-2026); pensada como pieza central del paquete de incorporación de septiembre de 2026.

La foto general

Somos un equipo de tres personas (Edu, Dani y Txell) construyendo CreaRack Pro ([[workspace—producto—que-es-crearack-pro]]). Nuestra particularidad: trabajamos en pareja con una inteligencia artificial — cada uno tiene su propio “Claude” (el asistente de Anthropic, en su versión para programar llamada Claude Code) configurado exactamente igual, con la misma memoria compartida del proyecto y las mismas reglas. A esa configuración común la llamamos el harness (el “arnés”: las barandillas que hacen que la IA trabaje bien y no se salga del camino).

El principio de fondo: la IA propone y ejecuta, la persona decide. Nada importante pasa sin que alguien del equipo lo haya pedido o aprobado.

El ciclo de una mejora, de la idea a producción

1. Idea — surge de nosotros, de un cliente o de un plan (el vigente es el Plan H2-2026). Si es grande, se discute y se escribe un plan antes de tocar nada (Regla 6: primero el plan, luego el código).
2. Contexto — antes de trabajar, Claude consulta la Biblioteca (la memoria del proyecto, ver más abajo) para saber qué hay hecho y cómo. Esto es obligatorio y el sistema lo comprueba solo (Regla 0).
3. Trabajo — Claude escribe el código con la persona al mando. Las barandillas actúan solas: revisores automáticos antes de cada guardado, límites de tamaño, avisos de estilo.
4. Pruebas — antes de compartir nada, la batería de tests completa se ejecuta en el ordenador de quien trabaja (en Docker, un entorno idéntico al servidor). Si algo está en rojo, no sale de ahí.
5. Revisión (PR) — los cambios grandes se suben como “Pull Request”: una propuesta de cambio que otro sistema automático (el CI de GitHub) vuelve a probar de cero. Un agente vigilante (“Vigía”) espera el resultado y avisa. Verde = se incorpora; rojo = se arregla antes. Los tres tenemos el mismo poder para aprobar e incorporar — no hay jerarquía de permisos (Regla 4/24).
6. Publicación — al incorporarse un cambio a la rama principal, el servidor se actualiza solo (Dokploy detecta el cambio, reconstruye y despliega, incluidas las migraciones de base de datos). Nadie sube nada a mano.
7. Verificación — quien hizo el cambio comprueba que funciona en la aplicación real (crearack.com). “El CI en verde” no basta: hay que ver el efecto (Regla 14).
8. Documentación — cada cambio deja rastro: el registro de cambios del repo, las notas de versión, la página de ayuda del usuario si le afecta (Regla 27) y el diario del equipo (WORKLOG, escrito en llano precisamente para que lo entienda cualquiera).

La memoria del proyecto (por qué Claude “se acuerda de todo”)

Un asistente de IA normal empieza cada conversación de cero. El nuestro no, gracias a tres capas:

• La Biblioteca (Supercontexto) — un “grafo de conocimiento”: todo el código, la wiki y las decisiones están indexados y Claude puede preguntarle en lenguaje natural (“¿cómo funciona el backup de configuraciones?”) antes de trabajar. Se reindexa sola cada noche en nuestro servidor.
• La wiki del workspace — cerca de 900 páginas: guías técnicas, decisiones tomadas (y por qué), incidentes pasados, ayuda del producto. Esta página es una de ellas.
• Las memorias del perfil — cada Claude guarda lecciones aprendidas (“esto salió mal así, no repetir”), que se comparten entre los tres perfiles.

Regla de oro asociada (Regla 19): cada sesión de trabajo empieza leyendo el estado y los pendientes (STATE/NEXT) y termina actualizándolos. Así cualquiera —persona o IA— puede continuar el trabajo de otro.

Sesión interrumpida: cómo se recupera el hilo

El cierre de sesión (actualizar STATE/NEXT/LOG/WORKLOG) es manual: si una sesión se corta a medias (apagón, emergencia, cuelgue), esos documentos se quedan por detrás de lo que el código ya tiene commiteado. No se pierde trabajo, pero el siguiente en llegar puede leer un estado viejo. El procedimiento de recuperación, para la siguiente sesión:

1. Comparar el final de STATE.md/NEXT.md con los commits reales (git log --oneline -15 en los repos tocados): los commits son la verdad; los documentos, el resumen.
2. Reconstruir el bloque de la sesión cortada en STATE.md + LOG.md a partir de esos commits (y del WORKLOG si llegó a escribirse), marcándolo como “(reconstruido, sesión interrumpida)”.
3. Revisar si quedó una rama sin despachar o un PR abierto (git branch -a, gh pr list) — eso es lo primero que se retoma o se descarta conscientemente.

Dos sesiones cerrando a la vez

WORKLOG.md y LOG.md se fusionan solos aunque dos personas cierren a la vez (merge “union”: los bloques de ambas sesiones se conservan). STATE.md y NEXT.md NO — se reescriben y podan, así que un cierre simultáneo puede dar conflicto: es intencionado, porque la máquina no sabe fusionar dos “estados actuales”. El último en pushear resuelve el conflicto conservando el bloque de sesión de ambos.

claude-method: el método empaquetado

Toda esta configuración vive en un repositorio propio, claude-method, que es la fuente única: los tres perfiles se sincronizan desde él automáticamente al arrancar cada sesión. Si Edu mejora una barandilla hoy, Dani y Txell la tienen mañana sin hacer nada.

Para comprobar que nadie se ha quedado atrás existe method-doctor: un chequeo que da VERDE o DRIFT (desfase) por perfil, con un panel central (/method-status) donde se ven los tres de un vistazo. Nota honesta (auditoría s185): a Dani y Txell les falta configurar un token para aparecer en ese panel — está en la lista de pendientes de septiembre.

Seguridad y copias de seguridad (resumen)

• Las llaves (contraseñas de servicios, claves de API) no viven en el código ni en la wiki: viven en los paneles de cada servicio y en una bóveda. Si ves una contraseña escrita en un documento, es un error — avisa.
• Las copias: la base de datos de producción se copia cada noche fuera del servidor, con capacidad de recuperar hasta un punto con ~15 minutos de pérdida máxima; los datos del workspace se copian a diario y a Google Drive cada semana. El manual completo (qué se copia, dónde, cómo se restaura): [[crearack-tech—guides—seguridad-y-backups]].
• Si algo se cae: hay guías de emergencia paso a paso pensadas para seguirse sin conocimientos técnicos — [[workspace—guias—disaster-recovery-workspace]] (el workspace) y [[crearack-tech—guides—disaster-recovery]] (la aplicación).

Las reglas de oro, en una frase cada una

Las ~27 reglas completas viven en el CLAUDE.md del repo (las lee la IA en cada sesión). Las que definen la cultura:

• Biblioteca primero — nunca trabajar de memoria pudiendo consultar la fuente (R0).
• Plan antes que código en lo complejo (R6) · lo definitivo antes que el parche (R22).
• Equipo plano: los tres subimos, aprobamos e incorporamos por igual (R4/R24).
• Tests en local antes de compartir (R18) · verificar el efecto, no la señal (R14).
• Nada de datos falsos ni apaños que simulen funcionar (R13).
• Ninguna deuda sin dueño: lo que se aplaza queda apuntado con plan y responsable (R23).
• Infraestructura crítica en servidores, nunca en el PC de nadie (R17).
• Documentar en cada cambio, con doble versión: técnica y en llano (R3/R27).

Glosario mínimo

Véase también

• [[workspace—producto—que-es-crearack-pro]]
• [[workspace—onboarding—setup-equipo-nuevo]]
• [[crearack-tech—guides—seguridad-y-backups]]
• [[concept—workspace—supercontexto-00-vision]]
• [[workspace—guias—team-processes]]