Procesos y Sistemas Automáticos — CreaRack Pro

Handbook del equipo: Documento de referencia para todo el staff. Describe todos los sistemas automáticos, procesos de trabajo y herramientas tanto del producto (CreaRack-Pro) como del workspace (CreaRackSL-workspace).

Audiencia: Edu, Dani, Txell — no requiere conocimientos técnicos profundos.

Última actualización: 24-07-2026 (s235 · pasada anti-rancio: Tailscale→NetBird, servidor OPS, costes de factura real, 28 reglas). Anterior: 24-05-2026 (s82).

1. Vista General

CreaRack Pro tiene dos repositorios y múltiples sistemas automáticos:

CreaRackSL-workspace          CreaRack-Pro
(equipo + procesos)           (código + producto)
├── WORKLOG.md        ←sync→  ├── RELEASE_NOTES.md
├── AI_WORKFLOW.md             ├── FEATURE_CATALOG.md
├── agents/ (15 IA)            ├── CHANGELOG.md
└── profiles/ (3)              └── Documentation/ (60+ docs)

                    Producción (Hetzner)
                    ├── crearack.com (app)
                    ├── Backups automáticos
                    ├── Monitorización 24/7
                    ├── Staging server
                    └── Servidor OPS (runners CI + crons)

2. Repositorios

Igualdad de accesos — equipo plano de 3, cualquiera ha de poder sustituir a cualquiera. Edu/Dani trabajan principalmente código y Txell BIZ, pero todos tienen permisos Write en los 3 repos. Ver §11 · Igualdad de accesos del staff.

3. Sistemas Automáticos en Producción

3.1 Backups (3 niveles)

Destino offsite: Hetzner Object Storage (bucket crearack-backups, región nbg1)

En caso de desastre: Ver Documentation/guides/DISASTER_RECOVERY.md — procedimiento de 8 pasos para restaurar desde cero.

3.2 Monitorización

3.3 CI/CD

3.4 Tareas Automáticas (Huey)

3.5 Backups del Workspace (D1)

3.6 Mirror de Emergencia del Workspace

Existe una copia estática del workspace en el servidor staging, accesible cuando Cloudflare cae:

• URL: http://100.96.254.204:8090 (STAGE vía NetBird)
• Acceso: credencial por canal privado — pídesela a Edu (no se documenta en claro aquí).
• Puerto 8090: Cerrado por defecto en Hetzner Firewall. Se abre solo en emergencia.
• Guía completa: docs/guides/DISASTER_RECOVERY_WORKSPACE.md

3.7 Firewall

3.8 Auto-Reports (Informes con IA)

El workspace incluye un sistema de generación automática de informes en /reports:

Toggle de tono: Cada informe permite cambiar entre tono Coloquial (fácil de leer, orientado a negocio) y Técnico (detallado, con métricas y comandos). Los informes se generan con Gemma 4 (gemma-4-26b-a4b-it vía Google AI Studio Paid Tier) a partir de datos reales del sistema.

Comandos de generación (desde el servidor):

• python manage.py perf_review — genera Performance Review
• python manage.py finops_report — genera FinOps Report

Acceso web: workspace.crearack.com/reports

4. Servidores

3 servidores productivos de CreaRack (PROD, STAGE, OPS) + Object Storage offsite + el servidor DCA (proyecto aparte channelassistance.com, misma cuenta Hetzner). El server self-hosted pve-epyc-02 fue dado de baja en s53 (08-05-2026) tras migrar toda la inferencia IA a Google AI Studio (Gemma 4):

Panel Dokploy: Puerto 3000 en PROD/STAGE — acceso vía NetBird. VPN NetBird (Cloud Free · sustituyó a Tailscale en s85): grupo servers con PROD + STAGE + OPS + DCA; las máquinas del staff entran por SSO. ⚠️ Con GlobalProtect activo, la resolución DNS netbird.cloud se rompe — usar las IPs directas de la tabla. Setup: claude-method/guides/NETBIRD_SETUP.md · runbooks runbook--infra--hetzner-firewall-solo-netbird y runbook--infra--netbird-proxies.

5. Procesos de Documentación

5.1 Documentos que se actualizan con cada cambio

5.2 Documentos de referencia (se actualizan cuando cambia algo)

5.3 Convención de commits

Política unificada desde 30-04-2026 con upgrade a GitHub Pro. Antes la convención era acumular docs con [skip ci] para ahorrar minutos Free; eso saltaba deploys e indexers que sí queremos correr.

6. Trabajo con Claude

6.1 Herramientas por persona

“Repo donde trabaja habitualmente” describe el área de foco diario. Acceso a los 3 repos es idéntico para los 3 (Regla 24 de CreaRack-Pro / Regla 15 del workspace). Cualquiera puede tocar cualquier repo cuando sea necesario.

6.2 Cómo funciona Claude Code

1. Al iniciar sesión, Claude lee automáticamente CLAUDE.md + documentos enlazados.
2. Los 4 hooks SessionStart (s60) se ejecutan en cadena: git pull --rebase del repo activo → hot-cache-sync.ps1 (refresca project_hot_cache.md con foto del estado actual) → timezone-sync (inyecta hora local + TZ Europe/Madrid, Regla 25) → claude-method-sync.ps1 -SkipHook -SkipMemory (pulea claude-method y propaga global-agents/ + global-skills/ a ~/.claude/, cierra Gap 1 del propagador del staff).
3. Tiene acceso SSH a producción y staging (vía NetBird) para diagnósticos.
4. Sigue las 28 reglas de oro (idioma, docs, git, modularización, etc.) — fuente de verdad: CreaRack-Pro/CLAUDE.md.
5. Tiene memorias persistentes por desarrollador (preferencias, errores conocidos, estado de proyectos).
6. Antes de cada commit con código (Fase 2 Supercontexto, Abril 2026): Claude ejecuta bib_report_change para cada archivo modificado. El hook scripts/harness/bib_report_check.py bloquea el commit si esto no se hizo. Bypass puntual: BIB_SKIP=1 git commit (queda registrado en /biblioteca/pulse).
7. Al final de sesión: actualiza RELEASE_NOTES, WORKLOG, y hace backup dual de memorias (C:/dev/claude-method/harness/claude-backup.ps1 -PushGit → OneDrive + repo claude-backups).

6.2.1 Panel en vivo del proyecto

https://workspace.crearack.com/biblioteca/pulse — foto del proyecto actualizada cada 60s: actividad 24h, alertas activas, tareas urgentes, salud del grafo, commits 7d, docs desactualizados (drift) y bypasses recientes del hook. Usar como check matutino.

6.2.2 Vigilante de documentación desactualizada (Escriba)

Un cron diario (04:15, en el servidor OPS desde la migración de crons) detecta documentos cuyo código asociado fue reportado con bib_report_change después de la última actualización del doc. El escriba está armado (dry_run=0 desde s201) — sus alertas son reales. El resultado aparece en la tarjeta “Docs desactualizados” del Pulse.

6.3 Cómo funciona Claude Code (Txell)

1. Abrir Claude Code en C:\dev\CreaRackSL-workspace
2. Claude lee CLAUDE.md automáticamente y carga los 5 agentes BIZ
3. Txell trabaja en español — Claude gestiona archivos y git automáticamente
4. Los documentos generados se guardan en docs/ y se comparten via git push

Claude Code permite a Txell trabajar sin copiar texto, abrir editores ni ejecutar comandos git. Guía completa: [[workspace—onboarding—onboarding-txell]] (wiki).

6.4 Agentes IA disponibles (15)

6.5 Memorias de Claude (per-dev, no compartidas)

Cada instancia de Claude Code tiene memorias propias:

• user_*: Perfil del desarrollador
• feedback_*: Directivas de trabajo aprendidas
• footguns_*: Errores técnicos a evitar
• infra_*: Configuraciones de infraestructura
• project_*: Estado de proyectos activos

Las memorias NO están en git. Se hace backup con C:/dev/claude-method/harness/claude-backup.ps1 al final de sesiones significativas. Los backups se guardan en %USERPROFILE%\claude-backups\<project-key>\ con retención 10. Restaurar con el flag -Restore.

Sincronización del método (s60, 13-05-2026): el 4º hook SessionStart pulea claude-method y propaga global-agents/ + global-skills/ automáticamente en cada sesión Claude Code. Si Edu o Dani suben un agente/skill nuevo via claude-method-promote.ps1, los demás lo reciben en su próxima sesión sin acción manual. Las memorias compartidas (shared-memory/) siguen propagándose vía setup-claude-code.ps1 para no pisar memorias locales divergentes.

Si necesitas forzar el sync fuera de una sesión Claude Code:

powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1

Ascender un agente o skill local al método central (s60, cierra Gap 2):

pwsh -NoProfile -File C:/dev/claude-method/harness/claude-method-promote.ps1 `
    -Type {agent|skill} -Name <slug>

Detecta CREATE/UPDATE/IDENTICAL, valida frontmatter (name: + description:), commit + push. Convención humana: “¿esto es transversal o solo del proyecto?” — si es del proyecto, va en <repo>/.claude/skills/, no en el central.

7. Reglas de Oro (resumen)

Resumen de las primeras 12 reglas (hay 28 en total, Regla 0 a 27 — fuente de verdad completa: CreaRack-Pro/CLAUDE.md):

8. Cuentas de Servicio

Credenciales y accesos documentados en las memorias de Claude (acceso restringido per-dev). Catálogo completo: [[entity—ops—catalogo-servicios-externos]].

9. Qué hacer si…

Todas las acciones son ejecutables por cualquiera del staff (Regla 24 / Regla 15 igualdad de accesos). Lo que requiere ayuda externa está marcado.

10. Igualdad de accesos del staff

Principio operativo del equipo (verbalizado 02-05-2026): “todos los miembros del staff han de tener los mismos accesos, en esta estructura tan sencilla de 3 miembros todos han de poder sustituir a cualquiera en cualquier momento”.

Equivalente a la Regla 24 de CreaRack-Pro/CLAUDE.md y la Regla 15 de CreaRackSL-workspace/CLAUDE.md.

Qué es idéntico para los 3

Qué es personal por miembro (no se sincroniza)

• Memorias propias en ~/.claude/projects/<repo-key>/memory/ (preferencias, errores aprendidos, contexto personal).
• settings.local.json (overrides personales sobre el settings.json base del equipo).
• Plugins user-scope que cada uno instale por gusto.
• Backup de memorias en %USERPROFILE%\claude-backups\ (local).

Cómo se mantiene la regla

• Cualquier cambio que afecte al harness/perfil/onboarding/credenciales/accesos se propaga en el mismo commit a los 3 onboardings (onboarding-edu, onboarding-dani, onboarding-txell) y a la documentación asociada (team-processes, claude-method, CLAUDE-PROFILE-ARCHITECTURE).
• El tono se adapta al perfil (Txell en lenguaje accesible) pero el contenido es equivalente.
• La excusa “X es el único que opera Y” NO es válida — si Y existe en el ecosistema, los 3 lo conocen.
• Cualquiera del staff que detecte una desviación (uno tiene un acceso que otros no, una credencial que solo está en el gestor de Edu) lo señala y se nivela.

Casos típicos donde aplica

• Migración de un servidor (s45: Hetzner Ollama → pve-epyc-02 · s85: Tailscale → NetBird · 07/2026: crons → OPS): los 3 onboardings actualizan el inventario.
• Nueva regla de oro o cambio de política (Regla 16 reformulada [skip ci], Regla 22 definitivo > rápido, Regla 23 no dejar deudas): replicada en CLAUDE.md de los 2 repos + onboarding-dani (lista de reglas).
• Nuevo servicio externo o cuenta: documentar acceso en reference_service_accounts de shared-memory + mencionar en los 3 onboardings.
• Cambio de procedimiento DR (mirror de emergencia, ramping): se documenta en team-processes + se actualizan los 3 onboardings con quién puede activarlo (todos).

Casos que NO aplican (verdaderamente personales)

• Edu prefiere temas oscuros y Dani temas claros — no se propaga.
• Plugins instalados por gusto personal en ~/.claude/plugins/ — no se propaga.
• Memorias personales aprendidas en una sesión privada — no se propaga.

11. Onboarding del equipo

La instalación de un equipo nuevo desde cero (PowerShell 7, herramientas, repos, tokens, primera sesión) vive en una fuente única: [[workspace—onboarding—setup-equipo-nuevo]]. No dupliques esos pasos en otros docs — un cambio de setup se hace en un solo sitio.

Las fichas personales cubren solo lo específico de cada rol (qué pedirle a Claude, áreas de foco, accesos):

• [[workspace—onboarding—onboarding-edu]]
• [[workspace—onboarding—onboarding-dani]]
• [[workspace—onboarding—onboarding-txell]]

Mantenido por: Equipo CreaRack

Véase también

• [[workspace—que-es-workspace]] — qué es Workspace
• [[workspace—guias—workspace-user-guide]] — guía de usuario
• [[workspace—onboarding—setup-equipo-nuevo]] — guía única de instalación desde cero
• [[workspace—onboarding—onboarding-edu]] — onboarding Edu
• [[workspace—onboarding—onboarding-dani]] — onboarding Dani
• [[workspace—onboarding—onboarding-txell]] — onboarding Txell
• [[workspace-tech—tecnico—ai-workflow]] — AI workflow del equipo