Onboarding Edu

Guía de referencia · Edu

CreaRack Pro · Flujo de trabajo completo Última actualización: 03-08-2026 (des-ranciado post-plugins: merge manual y push blindado en vez de auto-merge, Regla 14 sin --limit 1, sync por hash sin copiar agents/skills, Design Toolkit → plugin opcional method-design, SSH solo-NetBird + servidor OPS, gate Regla 0 opt-in en el plugin method, antesala + WAGERS, skills nuevas del método). Anterior: 24-05-2026 (s82 · onboarding rehecho de punta a punta: PS7 primero, prereqs, descarga autenticada, tokens reales, shortcut automático, “Apaga”, harness completo propagado)

Para instalar tu entorno desde cero (PowerShell 7, herramientas, repos, tokens, primera sesión): sigue la guía única [[workspace—onboarding—setup-equipo-nuevo]]. Esta ficha solo cubre lo específico de tu rol.

Estructura de directorios

C:\dev\
├── CreaRack-Pro\           → código fuente de la aplicación
├── CreaRackSL-workspace\   → contexto Claude + documentación del equipo
└── claude-method\          → harness, onboarding scripts, método compartido

Repos en GitHub

Flujo de trabajo diario

Inicio de sesión de desarrollo

cd C:\dev\CreaRack-Pro
git pull origin main
docker compose up -d
claude

Claude Code leerá CLAUDE.md automáticamente — no hace falta hacer nada más.

Atajo · acceso directo “Claude CreaRack” en el escritorio

Desde s82 el bootstrap lo crea automáticamente (paso [4d] del setup): devs → “Claude CreaRack” sobre CreaRack-Pro, COO → “Claude Workspace” sobre el workspace. Crea un .lnk que abre Windows Terminal con PowerShell 7, ejecuta claude update y entra en claude apuntando al repo. Igual para Dani y Txell por Regla 24.

Para recrearlo a mano:

pwsh C:\dev\CreaRack-Pro\scripts\windows\install-claude-shortcut.ps1

Fin de sesión · protocolo “Apaga”

Claude Code gestiona el cierre completo de cada sesión. Tú no tienes que recordar los pasos — basta con escribir la palabra clave “Apaga” (o “Apaga y vamonos”) y Claude ejecuta el ritual completo sin preguntar nada más.

Qué hace Claude al recibir “Apaga”:

1. Supercontexto (si la sesión lo tocó): actualiza public/supercontext/STATE.md con snapshot de lo trabajado + añade entrada nueva en LOG.md. NEXT.md se actualiza solo si cambió el backlog.

2. WORKLOG del workspace: añade bloque del día con bullets de lo que se hizo (formato híbrido: resumen coloquial para Txell + detalle técnico). Siempre, toque Supercontexto o no.

3. Tag opcional supercontext/sesion-N-done si la sesión fue significativa.

4. Pre-push check Sync Cascade (s80, 22-05-2026): si modificaste algún doc wiki con campo mirrors: en su frontmatter, Claude actualiza los espejos en el mismo commit (proactivo). Si se le olvida, el sistema Sync Cascade dispara igualmente con PR drafts auto-propuestos (reactivo). Detalle: [[feature—supercontext—sync-cascade]] + [[runbook—workspace—pausar-sync-cascade]].

5. Commits + push con flujo correcto: git pull --rebase origin main antes de cada push (Regla 4). Particiona commits si tocan múltiples repos. En CreaRack-Pro el push va SIEMPRE vía scripts/ci/safe_push.sh <rama> (pre-check de zombis de pushes anteriores + push con gate + verificación del SHA remoto por API). El ciclo completo push→CI→merge es delegable al agente crearack:estibador en background.

6. Verificar CI tras push (Regla 14): comprobar TODOS los workflows del commit (gh run list --json conclusion,name — NUNCA --limit 1). Lo hace el agente crearack:vigia en background; tras sus ráfagas Claude verifica el efecto real (git status + HEAD vs origin). Si el CI está rojo, NO se da la sesión por cerrada hasta investigar.

7. Auto-review PR drafts Sync Cascade (s80, 22-05-2026): si quedan PR drafts abiertos con etiqueta sync-cascade-proposal, Claude los procesa con criterio:

   • Cambios triviales (≤30 LOC, sin tocar owners/fechas/credenciales, Haiku sin dudas) → auto-merge.
   • Cambios con retoque obvio (typo, tono inconsistente) → Claude edita + mergea.
   • Cambios dudosos o grandes → pregunta antes de actuar.
   • Reporte final tipo: “Procesados N PRs · M auto-mergeados · K editados · L pending pregunta: […]”.

8. Memorias: actualiza memorias locales si emergieron aprendizajes (feedback_*, footguns_*, project_*).

9. Backup memoria (dual): ejecuta claude-method/harness/claude-backup.ps1 -PushGit para sesiones significativas. Hace .zip a OneDrive + memoria en texto al repo CreaRackSL/claude-backups (carpeta por persona). Recuperar en PC nuevo / memoria perdida: claude-backup.ps1 -Restore -FromGit -Name edu.

Variantes aceptadas: “Apaga”, “Apaga y vamonos”, “apaga”. No tienes que explicar nada más — Claude lo entiende.

Si solo quieres pushear cambios sin cerrar la sesión: ten en cuenta que main está protegida con status checks — el push directo de CÓDIGO lo rechaza (GH006), así que en la práctica código = rama + PR, y el merge al verde es MANUAL (gh pr merge <N> --squash; --auto falla). El push directo a main solo vale para docs-only. En CreaRack-Pro, pushear vía scripts/ci/safe_push.sh <rama>; el ciclo completo lo despacha crearack:estibador en background.

Gestión del workspace

Cuándo actualizar el workspace

Solo ante cambios significativos — no en cada commit:

• Nueva dependencia o cambio de versión relevante
• Nuevo módulo o app Django
• Cambio de arquitectura o decisión técnica importante
• Nueva integración (API, servicio, herramienta)

Claude Code lo hará automáticamente cuando detecte estos cambios y te avisará con: ⚠ CreaRackSL-workspace actualizado: [archivos modificados]

Actualización manual del workspace

Si necesitas editar algo manualmente:

cd C:\dev\CreaRackSL-workspace
# Editar el archivo correspondiente
git add .
git commit -m "sync: [descripción del cambio]"
git push origin main

Archivos del workspace y cuándo tocarlos

Reglas del proyecto post-Supercontexto

Desde el cierre del roadmap Supercontexto (22-04-2026) hay un bloque de reglas operacionales aplicable a toda sesión Claude Code en CreaRack-Pro o workspace. Claude las sigue automáticamente; esta sección es tu referencia para revisarlas.

Detalle de cada regla en CreaRack-Pro/CLAUDE.md § 1 (tabla resumen) + CreaRack-Pro/context/RULES_DETAIL.md (ampliaciones, historial “aprendido el día X” y matices operativos por regla).

La antesala (s207) + apuestas (27-07-2026) — ante una decisión de nivel (negocio/producto/arquitectura, “¿construimos X?”), Claude primero evalúa qué herramienta de deliberación encaja (/method:divergir · /method:grill · /method:roast · /method:storm · /method:plan-review) y te la propone con SU recomendación; la decisión no se cierra con el GO sino con una apuesta pre-registrada (qué esperamos, contra qué baseline, cuándo se evalúa) en CreaRackSL-workspace/public/supercontext/WAGERS.md. Detalle: CreaRack-Pro/.claude/rules/antesala.md.

Hook automático WORKLOG (sesión 27)

Tu Claude Code tiene un Stop hook configurado que dispara un reminder en stderr cuando detecta ≥3 commits combinados en CreaRack-Pro + workspace en las últimas 4h. Cumple Regla 12 sin disciplina manual. El reminder solo aparece 1 vez al día (marker idempotente en ~/.claude/projects/<key>/last-worklog-stamp.txt). Configurado por setup-claude-code.ps1 con -WorklogReposPaths + -GitAuthor.

Hook automático timezone-sync (sesión s50, 06-05-2026)

Tu Claude Code tiene un tercer comando en el hook SessionStart que ejecuta Get-Date al arrancar e inyecta una línea [Local time] yyyy-MM-dd HH:mm:ss +02:00 (Romance Standard Time) en el contexto de la sesión. Sirve para que Claude use tu reloj real (Europe/Madrid) en vez del currentDate UTC del system prompt — que viene sin hora y a veces va desfasado 1 día. Cumple Regla 25. Configurado por setup-claude-code.ps1, propagado por igualdad de accesos (Regla 24) a Dani y Txell.

Hook automático claude-method auto-sync (sesión s60, 13-05-2026 · actualizado s186)

Tu Claude Code tiene un cuarto comando en el hook SessionStart que ejecuta claude-method-sync.ps1 -SkipHook -SkipMemory envuelto en try/catch + exit 0. Hace git pull --rebase del repo C:\dev\claude-method y una convergencia POR HASH de shared-memory/, global-rules/ y settings-base hacia tu perfil. Los agents y skills ya NO se copian a ~/.claude/ (así era hasta s186): viajan en los plugins del método, que se leen EN VIVO del repo — el propio pull los mantiene al día. Cierra el Gap 1 del propagador: si tú añades una skill nueva al método central, Dani y Txell la reciben automáticamente la siguiente sesión sin ejecutar nada a mano. Los flags:

• -SkipHook: el pre-commit hook ya lo instala install_hooks.sh cuando hace falta. No queremos reinstalarlo en cada sesión.
• -SkipMemory: las memorias compartidas se gestionan en el bootstrap inicial. No queremos que cada sesión las pise si has divergido localmente.

El wrapper try/catch + exit 0 garantiza silent failure si estás offline o hay un conflict de rebase: la sesión arranca igual y resuelves el rebase la próxima vez que pulles manualmente. Coste: ~2-3s extra al arranque cuando el repo está al día. Configurado por setup-claude-code.ps1, propagado por igualdad de accesos (Regla 24) a Dani y Txell.

Promover local → central · claude-method-promote.ps1 (sesión s60 · actualizado a plugins)

Inverso del auto-sync. Cuando creas un agente o una skill localmente en ~/.claude/{agents,skills} y decides que merece ser transversal del staff, el script C:\dev\claude-method\harness\claude-method-promote.ps1 lo “asciende” al plugin correspondiente del método + commit + push automático. Cierra el Gap 2 del propagador (cerrado en la misma sesión s60 tras el Gap 1).

Flujo en una línea:

pwsh -NoProfile -File C:/dev/claude-method/harness/claude-method-promote.ps1 `
    -Type agent -Name <name> -Plugin <method|crearack|method-design|method-marketing>
# o:
pwsh ... -Type skill -Name <name> -Plugin <plugin>   # -Plugin por defecto: crearack

El script detecta automáticamente la acción a tomar:

• CREATE (destino no existe) → procede automático.
• UPDATE (destino existe + diverge) → aborta con diff resumen; re-invocar con -Force para sobrescribir intencionalmente.
• IDENTICAL (hash igual) → no-op, exit 0 silencioso.
• ERROR (source no existe / frontmatter inválido) → aborta listando lo disponible o explicando qué falta.

Validación de frontmatter obligatoria: el agente o skill debe tener name: + description: en el YAML. Sin description, Claude nunca lo invoca, así que el script bloquea el promote.

Modos: -DryRun (imprime qué haría sin tocar), -NoCommit (copia pero no commitea), -NoPush (commitea pero no pushea), -Force (necesario para UPDATE).

Convención humana — el filtro que NO automatiza el script: antes de invocar el promote, pregúntate “¿esto es transversal — útil para los 3 miembros del staff en cualquier proyecto — o solo del proyecto X?”. Si es del proyecto, vive en <repo>/.claude/skills/ (project-scope, ya trackeado en git con el repo), NO en el método central. El central es para tooling cross-project.

Tras el push, Dani/Txell lo reciben automáticamente la siguiente sesión vía el pull del SessionStart (los plugins se leen en vivo del repo). Propagador bidireccional cerrado: Edu crea → promote → los demás reciben sin acción manual.

Sistemas nuevos · sesión 80 (22-05-2026)

Tres mejoras operativas importantes que afectan al día a día del staff:

Bibliotecario-Ingest Batch

Cuando mergeas un PR significativo, el Bibliotecario genera automáticamente las wikis derivadas (entity pages, feature pages…). Antes lo hacía como N commits separados que disparaban N deploys CF Pages encadenados (15-20 min de cascada). Desde s80 lo consolida en 1 solo commit wiki(batch): N pages tras PR #X con todas las wikis nuevas dentro vía GitHub Trees API multi-file. Resultado: deploys post-merge de 2 min en vez de 15. Documentado en [[feature—biblioteca—bib-ingest-batch]].

Sync Cascade · mantener docs vinculados al día

Algunos docs son “espejos” entre sí (los 3 onboardings, técnico↔coloquial, catálogos↔credentials). Cuando cambias uno, el sistema detecta sus espejos vía el campo mirrors: del frontmatter y propone los cambios equivalentes via PR drafts auto-generados por Haiku. Tú revisas y mergeas (o cierras si Haiku se equivocó). El widget Pulse muestra cuántas cascadas hubo en 7 días + cuántos espejos pendientes. Toggle de emergencia SYNC_CASCADE_PAUSADO documentado en [[runbook—workspace—pausar-sync-cascade]]. Plan completo: [[feature—supercontext—sync-cascade]].

Cómo revisar los PR drafts:

1. Abre el Pulse (workspace.crearack.com/biblioteca/pulse).
2. Sección “Mirror cascades · 7d” → click en “Ver PR drafts” (link arriba a la derecha de la sección).
3. GitHub te abre la lista filtrada por etiqueta sync-cascade-proposal.
4. Para cada PR: abrir → revisar el diff propuesto por Haiku → si convence, Ready for review + Squash and merge. Si Haiku se equivocó, Close sin mergear.
5. Si pediste a Claude el “Apaga” antes de cerrar la sesión, Claude procesa estos PR drafts automáticamente con criterio (cambios triviales auto-merge, dudosos te pregunta).

Coste y frecuencia esperada:

• Cada cascada cuesta entre $0.02 y $0.08 por par fuente↔espejo (llamada a Haiku 4.5).
• Frecuencia esperada: ~5 cascadas/mes durante uso normal. Para un par como onboarding-edu↔dani+txell+team-processes, una sola edición sustancial dispara hasta 3 PR drafts. Coste total típico: $0.05-0.20/mes para el staff de 3.
• Si en alguna sesión vas a hacer un cambio masivo a 10+ wikis sembradas (ej. refactor del esquema email-routing afectando varias guías), activa primero el toggle de pausa para evitar 30+ PR drafts simultáneos.

Qué cambios NO disparan propuestas (Haiku rechaza):

• Cambios cosméticos: refresh de fechas, typos, ajustes de formato, mover comas.
• Cambios sin impacto sustantivo en el doc-espejo (tema independiente).
• Cambios donde Haiku tiene dudas sobre cómo trasladarlos (en duda → rechaza).

En esos casos el doc-espejo queda igualmente con verification_pending=1 en el widget Pulse, lo que sirve como recordatorio suave de revisar a mano sin generar PR draft automáticamente.

WebRTC peer-to-peer · video reuniones del equipo

Reemplaza el modal Jitsi que se quedó en s79. Click en “Video” del chat → modal flotante + signaling D1 + STUN público. Cuando alguien inicia reunión, el chat recibe aviso ”📞 X ha iniciado reunión. Únete: …” con un botón 🎥 Unirme que abre el modal en la misma pestaña (no pierde tu sesión del workspace). Sin Docker, sin server de medios. Documentado en [[feature—workspace—webrtc-peer-to-peer]] + [[entity—meeting—component—meeting-room]].

Biblioteca (Supercontexto)

La Biblioteca es un grafo de conocimiento que mapea código a documentación + una wiki Supercontexto auto-mantenida por bibliotecarios latentes (Ingest post-merge, Curator diario, Lint diario, Utility diario). Claude Code la consulta automáticamente para obtener contexto bajo demanda.

Flujo obligatorio en cada commit con código (hook bloquea si falta)

1. Antes de editar: bib_context_query(topic="<app>") → qué modelos/endpoints/docs hay.
2. Antes de commitear: bib_impact_query(file_path="<ruta>") → qué docs actualizar.
3. Antes de commitear (desde 2026-04-20): bib_report_change(file_path="...", change_type="modified") por cada archivo tocado. El hook bib_report_check.py bloquea el commit si falta. Bypass puntual: $env:BIB_SKIP=1; git commit (queda registrado en el Pulse).

Además, el gate de la Regla 0 (bloquea la primera edición/SSH/deploy de la sesión si no consta una consulta bib_*) vive desde el 03-08-2026 en el plugin method y es opt-in por marcador .claude/bib-gate.json — los repos CreaRack lo llevan commiteado. Bypass puntual: BIB_GATE_SKIP=1 (si el gate no bloquea cuando debería, sospecha de esa env var en el scope User de Windows antes que de un bug).

Herramientas MCP principales

Skills bibliotecario (disponibles en workspace y CreaRack-Pro)

Panel en vivo

Abrir cada mañana: https://workspace.crearack.com/biblioteca/pulse (auto-refresh 60s).

Credenciales del MCP workspace (3 capas — desde sesión 57, 12-05-2026)

Tu .mcp.json (en C:\dev\CreaRack-Pro\ y C:\dev\CreaRackSL-workspace\) lleva 3 headers desde el cierre s57. Las requests pasan dos puertas de auth antes de llegar al handler:

1. Authorization: Bearer <bearer-personal> — Bearer token de aplicación. Identifica al usuario (Edu/Dani/Txell) en el middleware del Worker. Cada miembro tiene el suyo. Vive en MCP_TOKENS (CF Pages env var, formato nombre:token,nombre2:token2,...).
2. CF-Access-Client-Id: <client-id>.access — Identificador del Service Token de Cloudflare Access. Compartido entre los 3 miembros.
3. CF-Access-Client-Secret: <client-secret> — Secret del Service Token. Compartido entre los 3. Solo se muestra UNA vez al crear el token en CF Zero Trust → Service Tokens (si se pierde, hay que regenerar).

Las dos primeras viajan al edge de Cloudflare y validan que la request puede llegar al Worker. El Bearer viaja al middleware y autentica al usuario individual. Sin los headers CF Access, las apps Critical (/api/biblioteca/, /api/mcp) devuelven 403 en el edge antes de tocar el Worker (tras s57 ya no hay bypass everyone).

Variables de entorno del usuario (Windows)

setup-claude-code.ps1 las guarda automáticamente al pasar los 3 parámetros al bootstrap:

• BIB_MCP_TOKEN — usado por scripts del proyecto (cron bib-reindex, hook SessionStart hot-cache) y el MCP.
• CF_ACCESS_CLIENT_ID + CF_ACCESS_CLIENT_SECRET — usadas por todo lo que llama al workspace fuera del cliente MCP: workflows GitHub, cron bib-reindex, scripts ad-hoc del repo, proxy Django del Help Widget (core/api_help.py en CreaRack-Pro · 3 callers: bib_ask + wiki list + wiki-titles), pre-commit hook (claude-method/harness/bib_report_check.py), contenedor Docker dev local (compose.yml las propaga al web service vía ${CF_ACCESS_CLIENT_ID:-}).

Verificar: [Environment]::GetEnvironmentVariable("CF_ACCESS_CLIENT_ID", "User") debe devolver tu Client ID. Si tu Help Widget local devuelve 500 “Expecting value: line 1 column 1 (char 0)”, esa env var quedó vacía o mal nombrada (footgun s58: CF_ACCESS_CLIENT_ID0 ≠ CF_ACCESS_CLIENT_ID — Dokploy/Windows no validan nombres de variable).

Regenerar el Bearer personal

1. Generar: python -c "import secrets; print(secrets.token_hex(24))"
2. Editar MCP_TOKENS en Cloudflare Pages (Settings → Environment variables → MCP_TOKENS) reemplazando tu entrada edu:<viejo> por edu:<nuevo>.
3. Redeploy el proyecto Pages para aplicar el cambio (footgun conocido: las env vars solo aplican en el SIGUIENTE deploy).
4. Actualizar .mcp.json local y la variable de entorno BIB_MCP_TOKEN.

Regenerar el Service Token CF Access (los 3 miembros)

Solo si se pierde el Client Secret o por rotación de seguridad. Panel CF Zero Trust → Access → Service Tokens → “Workspace API - Bibliotecario crons + MCP” → Regenerate. El nuevo secret se muestra una vez — pasarlo a Dani y Txell por canal privado y actualizar los 3 .mcp.json + env vars + GitHub secrets (CF_ACCESS_CLIENT_ID/SECRET) + Hetzner staging /opt/bib-reindex/.cf-access-id|secret.

⚠ NO añadir el connector workspace.crearack.com en https://claude.ai/settings/connectors. El connector web de claude.ai usa OAuth y no soporta headers custom — sus requests llegan a CF Access sin los 2 headers Service Token y reciben 403. Además, si está registrado, tiene precedencia sobre tu .mcp.json local y romperás el MCP. El connector OAuth fue eliminado en s57 a propósito; tu MCP funciona exclusivamente vía el .mcp.json local con los 3 headers.

Documentación completa

• Wiki: workspace.crearack.com/wiki → IA Tech → Biblioteca
• Supercontexto: CreaRackSL-workspace/public/supercontext/ (STATE.md · LOG.md · briefings/NEXT.md)

context7 MCP (docs externas frescas)

Desde sesión 28 (Abril 2026) Claude Code registra automáticamente el MCP context7 (HTTP público, sin token). Da acceso a documentación actualizada de librerías externas — útil cuando el conocimiento de Claude está desfasado o el corte temporal lo deja corto.

Tools disponibles: mcp__context7__resolve-library-id y mcp__context7__query-docs. Claude las invoca solo cuando aporten algo. Verificar registro: claude mcp list (debe mostrar context7: ... ✓ Connected).

Tests de validación (sesión 28): Django Channels + CONN_MAX_AGE → respuesta complementaria al ADR. Astro 5 content collections → confirmó que nuestro patrón es canónico + 1 hallazgo menor (entry.id ya no incluye .md en Astro 5).

Harness Engineering (controles de calidad)

El proyecto incluye un sistema de controles automatizados que validan cada commit y la arquitectura del proyecto. Vive en claude-method/harness/ y se ejecuta desde ahí: el pre-commit de cada repo (el que instala install_hooks.sh) invoca los checks en la fuente, sin copias locales.

Pre-commit hook · checks

Instalado en tu máquina. Cada git commit valida automáticamente:

Además del pre-commit, el pre-push de CreaRack-Pro es un gate rápido de tests del área tocada (Regla 18, scripts/ci/pre_push_tests.sh), y el push va envuelto en scripts/ci/safe_push.sh (ver protocolo “Apaga”).

Reinstalar el git hook en ambos repos:

bash C:/dev/claude-method/harness/install_hooks.sh

Fitness tests

docker compose exec web python -m pytest tests/test_architecture_fitness.py -v

CNS feedback loop

Tarea Huey automatica (cada 6h) que analiza las conversaciones de operadores con el CNS y extrae patrones aprendidos. Los patrones se inyectan en el StaticRulesProvider antes de las reglas hardcoded.

Documentacion completa

Documentation/guides/HARNESS_ENGINEERING.md — guia reutilizable para proyectos futuros.

Routines (agentes Claude programados en la nube)

Desde sesión 32 (27-04-2026) el ecosistema CreaRackSL tiene scheduled remote agents que corren en la infra de Anthropic, no en tu PC. Coste API (no Plan Max). Total ecosistema: <$10/mes.

Watcher Cluster C: routine ELIMINADA del panel — verificado por API el 04-08-2026 (ya no aparece en la lista de triggers). Su cometido (vigilar el fix d2653a1 de asyncssh) está en producción desde hace tiempo. Cerrado.

Patrón “watchdog cloud para cron server” (s50)

Nacido tras incidente s50: el cron de bib-reindex en STAGE estuvo parado 10 días silenciosamente por permission denied. Patrón general reusable para otros crons críticos:

[cron 10 min en server] ──► log archivo
                              ↑
                              │
[routine diaria en cloud] ─── lee MCP/HTTP del workspace
                              │
                              ├── si reciente → silencio
                              └── si viejo → gh issue create con diagnóstico

Reproducir el patrón si otro cron se queda silencioso (DR backup, gh-actions-watchdog, stale-check).

Lecciones clave del watchdog s50 (documentadas en memoria project_claude_routines_s50.md):

• MCP local ≠ MCP connector cloud — los connectors personalizados sí están disponibles para routines aunque no aparezcan en el prompt de /schedule
• GitHub access se desautoriza solo periódicamente — re-autorizar en https://github.com/settings/installations
• Mínimo 1 hora de frecuencia en cron — para crons cada 10 min seguir usando bash en server
• Las routines NO tienen SSH a tu infra — usan MCP/curl HTTPS, abren issues si necesitan acción humana
• Test run obligatorio tras crear (RemoteTrigger action=run) antes de confiar en el cron natural

Prompt del agente Mantenimiento Semanal vive versionado en CreaRackSL-workspace/public/supercontext/agents/maintenance-weekly.md — editar ahí cuando cambien tareas, lista de paquetes a vigilar o destinatarios.

Gestionar: skill /schedule desde Claude Code, o panel https://claude.ai/code/routines.

Apagar todas las routines: panel web → click → delete (no borrable vía API).

Plugins del método (s186 · dieta 28-07-2026)

Desde s186 las skills y agentes del método van empaquetados en 4 plugins con namespace, servidos por el marketplace local crearack-method (source directory: se leen EN VIVO del repo claude-method — el pull del SessionStart los actualiza; nada que copiar). Invocación con prefijo: /method:roast, /crearack:secre (el autocompletado las encuentra escribiendo el nombre a secas).

Los opcionales se activan con /plugin cuando hacen falta (apagados ahorran ~1.7k tokens de listado por sesión). Verificar tu perfil: /crearack:method-doctor; los 3 perfiles a la vez: /crearack:method-status.

Design Toolkit (s50 · plugin opcional method-design desde s186)

El staff comparte un toolkit de diseño: agente design-collaborator (model: opus) + 15 skills design-* (production, system, review). Desde s186 vive en el plugin method-design del repo claude-method (leído en vivo; el pull del SessionStart lo mantiene al día) y desde la dieta del 28-07-2026 es OPCIONAL y va apagado por defecto: actívalo con /plugin cuando toque diseño. Invocación con namespace: /method-design:design-polish-pass; el agente se lanza como method-design:design-collaborator.

Cuándo se dispara

• Skills: se auto-disparan cuando lo que pides matchea su descripción (“dame 3 variantes del hero” → design-generate-variations) — con el plugin activo.
• Agente: lo decide spawneear el Claude principal cuando la tarea es grande y especializada (rediseño completo, audit del frontend entero)
• Manual: /method-design:design-polish-pass, /method-design:design-discovery-questions, etc.

Catálogo rápido

Filosofía

Rechaza explícitamente las defaults genéricas que delatan “AI-template”: gradientes agresivos, emoji decorativo, cards border-radius: 12px; border-left: 4px solid por defecto, Inter/Roboto silentes, #FFF sobre #000 puro. Obliga a comprometerse con paleta + tipografía + densidad + motion.

Origen

Reverse engineering de Claude Design (Anthropic) por Trystan-SA, MIT. Repo upstream: https://github.com/Trystan-SA/claude-design-system-prompt. Adaptaciones a Claude Code (equivalencias de tools, prefijo design- en skills) en claude-method/plugins/method-design/ y claude-method/guides/DESIGN_TOOLKIT.md.

Documentación completa

• Wiki: [[crearack-tech—method—design-toolkit]]
• Guía técnica: claude-method/guides/DESIGN_TOOLKIT.md

Curator + Lint del Bibliotecario en apply=true

Desde sesión 32 (27-04-2026), los crons diarios Bibliotecario-Curator (05:00 UTC) y Bibliotecario-Lint (04:30 UTC) corren con apply=true por defecto:

• Curator promueve drafts aprobados por Haiku → active y borra los rechazados (acciones reversibles vía git history del repo + log MCP).
• Lint marca last_verified > 60 días como stale y persiste contradicciones detectadas.

Forzar dry-run puntual: gh workflow run "Bibliotecario-Curator" -f apply=false --repo CreaRackSL/CreaRackSL-workspace.

Claude Method (repo de metodo)

El metodo de trabajo con Claude esta empaquetado en un repo separado para reutilizarlo en proyectos futuros. Para arrancar un proyecto NUEVO con el método completo (harness + Biblioteca propia), el camino canónico es la skill /method:iniciar-proyecto (03-08-2026) — detalle en claude-method/guides/PROJECT_INITIALIZER.md.

Propagar mejoras al staff

El método tiene dos scripts de propagación complementarios, no equivalentes:

# Sync de memorias (manual, tras pushear nueva shared-memory al claude-method)
cd C:\dev\CreaRackSL-workspace
.\scripts\sync-method.ps1          # sincroniza a los 3 perfiles
.\scripts\sync-method.ps1 -DryRun  # solo muestra que cambiaria
.\scripts\sync-method.ps1 -Staff "Dani"  # solo un perfil

# Sync de rules/memorias/settings (ya automático en SessionStart; manual solo para debugging)
pwsh C:/dev/claude-method/harness/claude-method-sync.ps1 -SkipHook -SkipMemory

Gestión del equipo en GitHub Organization (s74, 19-05-2026)

Los 3 repos viven en la Organization CreaRackSL (no en User personal). Membership y permisos se gestionan a nivel Org, no por repo.

Invitar a un nuevo miembro

https://github.com/orgs/CreaRackSL/people → Invite member → username GitHub o email → seleccionar role:

• Owner: acceso admin total a los 3 repos + settings Org (billing, members, branch protections, security). Es el role estándar del staff plano (Regla 24 igualdad de accesos).
• Member: lectura por defecto (default_repository_permission: read); cada repo puede ampliar.

Para staff CreaRackSL la convención es Owner. Para colaboradores externos puntuales: Outside collaborator desde Settings → Collaborators del repo concreto, con scope mínimo necesario.

Estado actual del Org (verificable con gh api orgs/CreaRackSL/members)

Si alguien pierde acceso

1. Verificar que sigue como Member del Org: gh api orgs/CreaRackSL/memberships/<username> debe devolver state=active.
2. Si está como pending: re-enviar invitación desde https://github.com/orgs/CreaRackSL/people → buscar usuario → Resend invitation.
3. Si fue removido por accidente: re-invitar desde la misma URL.

Toggles Org críticos (NO cambiar sin auditar dependencias)

Detalle completo del mapa de credenciales y procedimientos de rotación: [[runbook—platform-credentials-map]].

Acceso SSH a Hetzner — vía NetBird

Tres servidores tras la baja del EPYC en s53 y el alta del servidor OPS:

Todo el acceso operativo a infra pasa por NetBird (NetBird Cloud; sustituyó a Tailscale en s85, 2026-05-25), y el SSH SOLO por NetBird es invariante desde s222: los firewalls Hetzner ya no aceptan :22 desde IPs públicas. Los servidores están en el grupo servers. Cualquier laptop del staff conectada a NetBird (login SSO) puede entrar por nombre (*.netbird.cloud) y acceder a los servicios internos; si los nombres no resuelven (footgun DNS conocido con GlobalProtect activo), usa las IP NetBird directas.

Comandos habituales

# (si el nombre no resuelve: IPs NetBird → PROD 100.96.156.31 · OPS 100.96.245.233)

# PROD — shell + docker
ssh root@crearack-prod
ssh root@crearack-prod "docker ps"
ssh root@crearack-prod "docker logs crearack-pro-zcmvsl-web-1 --tail 50"
ssh root@crearack-prod "docker restart crearack-pro-zcmvsl-web-1"

# STAGE — DR + staging
ssh root@crearack-staging "docker ps"

# Servicios internos accesibles directo desde tu laptop NetBird (sin docker exec ni SSH tunneling):
curl http://crearack-prod:8428/api/v1/query?query=up                # VictoriaMetrics
psql postgres://USER:PASS@crearack-prod:5432/DBNAME                  # PostgreSQL directo (DBeaver/pgAdmin)
# Browser:
# http://crearack-prod:3000   → panel Dokploy PROD
# http://crearack-staging:3000 → panel Dokploy STAGE

Contenedores PROD (crearack-pro-zcmvsl-*):

Server EPYC self-host LLM dado de baja en s53: tras migrar Help a AI Studio paid (s53), el pve-epyc-02 quedó sin uso y fue cancelado en Hetzner Robot tras wipe NIST SP 800-88. Toda la inferencia LLM corre ahora en Google AI Studio Paid Tier (gemma-4-26b-a4b-it).

Setup NetBird completo + troubleshooting + DNS + políticas (grupos users/servers): guía claude-method/guides/NETBIRD_SETUP.md + runbooks wiki [[runbook—infra—netbird-proxies]] y [[runbook—infra—hetzner-firewall-solo-netbird]].

Razón social vs marca comercial (s64, 14-05-2026)

Tras el cambio de denominación social del 14-05-2026 (mismo CIF, sin disolución), la convención del equipo es:

NO hacer sweeps masivos CreaRackSL → Esferic Labs SL en código o docs internas. El rename solo afecta a la capa legal/comercial. Lo interno se mantiene por trazabilidad histórica y porque el cambio rompería paths, remotes, hooks, env vars en cascada. Solo se actualizan los puntos donde aparece info legal (terminal/agent/licenses/ATTRIBUTIONS.txt, footer/ToS web crearack.com, perfil Holded, paneles billing cloud — Hetzner, Cloudflare, GitHub, Anthropic, etc.). Migración customer-facing diferida a cuando exista escritura notarial; owner: Edu/Txell con asesor legal.

Detalle completo: memoria personal project_esferic_labs_rename (también en shared-memory tras propagación s75).

Referencia rápida de comandos

Desarrollo

Workspace: management commands y paginas

Con observabilidad (VictoriaMetrics)

docker compose -f compose.yml -f compose.observability.yml up -d

URLs de desarrollo

Local Agent: desde la 2.17.0 se distribuye con instalador profesional Inno Setup (CreaRackAgent-Setup.exe) con auto-update silencioso, y desde la 2.18.0 reporta su salud en el heartbeat (visible en el Fleet Manager). Compilarlo requiere Inno Setup 6 — ver el Paso 6 de [[workspace—onboarding—setup-equipo-nuevo]]; pipeline completo en [[crearack-tech—guides—agent-distribution]].

Onboarding del equipo

Las guías personales de cada miembro están en la wiki:

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

La instalación de un equipo nuevo desde cero (incluida una máquina tuya nueva) es la guía única [[workspace—onboarding—setup-equipo-nuevo]] — un solo sitio, sin duplicar pasos.

Cambios recientes (mayo 2026 · sesiones 67-82)

Resumen ejecutivo de las novedades que afectan al flujo diario. Detalle en wikis enlazadas.

Integración Zoho ↔ Workspace (s67-s68, 16-17 mayo)

El workspace integra Zoho Calendar + Mail per-user:

• Tasks D1 sigue siendo Single Source of Truth — KanbanMini intacto.
• Zoho = canales de acción explícita desde TaskModal: + Crear evento Calendar · + Vincular email existente · + Nuevo email.
• Auto-eventos de ciclo de vida: crear/cerrar/reabrir/borrar tarea sincroniza eventos all-day en cada calendar implicado.
• Per-user OAuth: cada miembro autoriza su propia cuenta Zoho desde /settings/integrations/zoho.

Runbook operativo: [[runbook—zoho-integration-end-to-end]]. ADR vigente: [[decision—20260517—integracion-zoho-calendar-mail-pivot]] (supersede al ADR original s67).

8 grupos de email Zoho (s69, 18-05-2026)

Emails granulares por función + acción. Routing de notificaciones externas (GitHub, CF, Hetzner, Anthropic, Resend…):

factu + legal solo Txell → vigilar bus factor (si se ausenta, hay que reasignar). Detalle coloquial: [[workspace—guias—emails-equipo]]. Arquitectura técnica de routing: [[crearack-tech—admin—email-routing-architecture]].

Oráculo de EL (s72-s73, 19 mayo)

Asistente conversacional integrado en la caja de búsqueda del header de workspace.crearack.com. Detección automática:

• Queries cortas → Fuse fuzzy local (búsqueda en menús/páginas).
• Preguntas naturales → chat con Gemma 4 sobre el grafo Bibliotecario (corpus: 6 wikis + 49 docs claude-method + código TypeScript del workspace + código Python de CreaRack-Pro).

Chat multi-turno efímero (sin persistencia, cap 12 turnos servidor). Threshold relevance < 0.4 corta antes de llamar al modelo. Sources clicables (wikis abren internamente, claude-method va a GitHub web). Endpoint backend: POST /api/oraculo/ask. Detalle: [[feature—workspace—oraculo-de-el]].

Migración GitHub User → Organization (s74, 19-20 mayo)

Los 3 repos ahora viven en la Organization CreaRackSL (antes en el User personal CreaRackSL, ahora renombrado a CreaRackSL-bridge y en fase de borrado).

Estado actual:

• Owners del Org: Esquembri (tú) + Txell + Dani (los 3 con role admin, state active).
• Plan: Team $144/año (recuperamos branch protections que estaban en Pro User).
• URLs de los repos sin cambios (GitHub mantiene redirects desde el username antiguo).
• Branch protections en main de los 3 repos: force-push y deletions blocked. CreaRack-Pro además exige status checks (Backend · Frontend · Docker · Security) antes de merge PR.
• WORKSPACE_REPO_PAT regenerado fine-grained desde tu cuenta personal Esquembri.

Cabos sueltos en seguimiento:

• Pro de CreaRackSL-bridge aún activo · 2 tickets Support abiertos (refund discrecional + cancel auto-renewal). Mientras esperas respuesta: NO pulses “Downgrade to Free” en UI (pierde Pro inmediato sin cancelar renovación · ver memoria footguns_github_pro_cancel_renewal_ui).
• Aviso cosmético en CF Pages Dashboard (metadata huérfana apuntando a CreaRackSL-bridge). Aceptado status quo · no afecta operación.
• Cuenta CreaRackSL-bridge se borra cuando Dani acepte invitación + 1 semana de redirects estables.

Véase también

• [[workspace—onboarding—setup-equipo-nuevo]] — guía única de instalación desde cero
• [[workspace—onboarding—onboarding-dani]] — onboarding Dani
• [[workspace—onboarding—onboarding-txell]] — onboarding Txell
• [[workspace—perfiles—profile-dev]] — perfil dev
• [[workspace—perfiles—profile-biz]] — perfil biz
• [[workspace—guias—team-processes]] — procesos de equipo
• [[workspace-tech—tecnico—ai-workflow]] — AI workflow
• [[feature—method—onboarding-v2]] — Onboarding v2 + bootstrap-profile para devs nuevos
• [[runbook—zoho-integration-end-to-end]] — runbook Zoho operativo
• [[workspace—guias—emails-equipo]] — guía emails coloquial
• [[feature—workspace—oraculo-de-el]] — Oráculo de EL