CLAUDE-PROFILE-ARCHITECTURE

Esquema del perfil Claude del equipo CreaRackSL. Describe cómo está organizado el entorno Claude Code de los 3 miembros (Edu, Dani, Txell) y cómo se relaciona con el sistema transversal compartido (repos, MCP, Bibliotecario cloud). Documento vivo. Última actualización: 2026-08-14 (nueva superficie de propagación global-output-styles/ — el output style companero inyecta la norma de redacción en el system prompt con recordatorios a mitad de sesión; clave outputStyle sembrada en el settings base sin pisar la elección personal; paridad vigilada por method-doctor).

⚠️ Nota de vigencia: §2.4/§3.1 describen global-skills//global-agents/ copiados a ~/.claude/ — es el estado pre-plugins. Desde s186 (02-07-2026, Fase 2 de plugins) las skills/agents distribuibles viven en los plugins method y crearack (marketplace local tipo directorio); ver [[crearack-tech—method—harness-guide]] y [[ia-tech—metodo—runbook-cambios-harness]].

1 · Visión general

El equipo trabaja con 3 instancias locales independientes de Claude Code (Edu, Dani, Txell) que comparten un sistema transversal común — repos git, MCP workspace en Cloudflare y Bibliotecario (crons IA). La parte local diverge por persona (rol, memorias, preferencias); la parte transversal es idéntica para los 3.

                        Sistema transversal compartido
   ┌────────────────────────────────────────────────────────────────────────────────┐
   │                                                                                │
   │   Repos git (GitHub/CreaRackSL)                                                │
   │   ├── CreaRack-Pro ────── código producto + CLAUDE.md + .claude/skills/        │
   │   ├── CreaRackSL-workspace ─ hub agentes + supercontext/ + wiki + onb.         │
   │   └── claude-method ────── harness + onboarding scripts + shared-memory        │
   │                                                                                │
   │   Cloudflare (workspace.crearack.com)                                          │
   │   ├── MCP Worker ──────── tools bib_*, wiki_*, github_*, holded_*, ...         │
   │   ├── D1 databases ────── grafo + embeddings + wiki Supercontexto + eventos    │
   │   └── Biblioteca UI ───── /pulse · /biblioteca · /wiki                         │
   │                                                                                │
   │   Bibliotecario (autónomo, GitHub Actions sobre workspace)                     │
   │   ├── Ingest ──────────── on push:main + PR.closed (3-tier económico)          │
   │   ├── Curator ─────────── cron diario (archivado drafts)                       │
   │   ├── Lint ────────────── cron diario + consolidación semanal                  │
   │   └── Utility ─────────── cron diario (utility_score)                          │
   │                                                                                │
   └──────────────────────▲──────────────▲──────────────▲───────────────────────────┘
                          │              │              │
            ┌─────────────┴───┐  ┌───────┴──────┐  ┌────┴──────────┐
            │  Claude local   │  │ Claude local │  │ Claude local  │
            │     (Edu)       │  │    (Dani)    │  │   (Txell)     │
            │   CEO · Dev     │  │     Dev      │  │     COO       │
            │ ~/.claude/      │  │ ~/.claude/   │  │ ~/.claude/    │
            │ memoria propia  │  │ memoria prop │  │ memoria prop  │
            │ BIB_MCP_TOKEN   │  │ BIB_MCP_TOKEN│  │ BIB_MCP_TOKEN │
            │ settings propio │  │ settings pr. │  │ settings pr.  │
            └─────────────────┘  └──────────────┘  └───────────────┘
                Windows (Proxmox o bare metal)

Modelo mental: el perfil Claude del equipo es un todo distribuido. Los 3 comparten memoria profunda — claude-method + Bibliotecario cloud — y divergen en memoria individual (memorias personales + rol + preferencias UI). Para replicar el perfil en una máquina nueva: (a) instalar prereqs, (b) clonar los 3 repos, (c) ejecutar bootstrap-profile.ps1. El resto se hereda automáticamente.

Principio operativo · igualdad de accesos del staff (verbalizado 02-05-2026 por Edu): “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”. La parte transversal compartida (repos, MCP, Bibliotecario, accesos a Hetzner, cuentas de servicio, tokens MCP, skills, harness) es idéntica para los 3 miembros. Las diferencias viven exclusivamente en la parte local/personal. Cualquier cambio en harness/perfil/onboarding/credenciales/accesos se propaga a los 3 onboardings en el mismo commit. Documentado como Regla 24 en CreaRack-Pro/CLAUDE.md y Regla 15 en CreaRackSL-workspace/CLAUDE.md y desarrollado en [[workspace—guias—team-processes]] §11.

2 · Parte local / personal (por persona)

Todo lo descrito aquí vive en la máquina de cada miembro, no se trackea en git, y es independiente entre personas.

2.1 Claude Code CLI

• Instalación: npm install -g @anthropic-ai/claude-code.
• Ubicación: binario en el node_modules global; home en ~/.claude/.
• Actualización: automática (canal latest vía autoUpdatesChannel).

2.2 Settings (~/.claude/settings.json)

Generado por setup-claude-code.ps1 con los valores base del equipo:

Cada persona puede añadir overrides personales en ~/.claude/settings.local.json (no tocado por el bootstrap).

2.3 Memoria personal (~/.claude/projects/<repo-key>/memory/)

• Por persona + por proyecto: Edu tiene una memoria distinta a la de Dani para el mismo repo.
• NO se trackea en el repo de código. Backup dual vía claude-method/harness/claude-backup.ps1 -PushGit: .zip a OneDrive + memoria en texto al repo CreaRackSL/claude-backups (carpeta por persona). Recuperar: -Restore -FromGit -Name <persona>.
• Contenido inicial (copiado por el bootstrap desde claude-method/onboarding/shared-memory/): footguns genéricos + feedback de directivas.
• Contenido específico del workspace (copiado desde CreaRackSL-workspace/onboarding/shared-memory/): memorias operacionales del equipo.
• Contenido que crece sola: Claude añade memorias propias (correcciones, preferencias personales, contexto de proyectos activos).

El archivo índice MEMORY.md se carga al arrancar la sesión (truncado a 200 líneas).

2.4 Skills user-scope (~/.claude/skills/)

• Design Toolkit (s50, 06-05-2026): 14 skills design-* propagadas desde claude-method/global-skills/ por setup-claude-code.ps1 paso 4c. Anti-AI-slop. Ver [[crearack-tech—method—design-toolkit]].
• VibeSec-Skill (seguridad web, opcional): SKILL.md ~80KB, instalación manual.

El resto de skills del equipo (bibliotecario, etc.) viven en los repos y se cargan automáticamente cuando Claude arranca dentro del repo.

2.4.b Agents user-scope (~/.claude/agents/)

• design-collaborator (s50, model: opus): agente especializado en diseño UI/frontend basado en system prompt de Trystan-SA/claude-design-system-prompt MIT. Propagado desde claude-method/global-agents/ por setup-claude-code.ps1 paso 4c. Lo invoca el Claude principal cuando una tarea es lo bastante grande. Pares con las 14 skills design-*.

2.5 Plugins user-scope (~/.claude/plugins/)

Instalación manual vía /plugins install <name>:

• frontend-design (Anthropic official). Se mantiene registrado (disabled) — los 14 skills design-* viven en ~/.claude/skills/ user-scope, propagados por setup-claude-code.ps1 paso 4c, no dependen del plugin. Mantener registrado permite recibir updates oficiales del Design Toolkit.

Plugins descartados (s52, 07-05-2026 — limpieza por warning del harness “18 descriptions dropped” excediendo skillListingBudgetFraction 1%):

• andrej-karpathy-skills (forrestchang) — desinstalado. Sus directrices comportamentales (Pensar antes de codificar · Simplicidad primero · Cambios quirúrgicos · Ejecución dirigida por objetivo) están ahora embebidas en CLAUDE.md sección 12 del repo CreaRack-Pro (atribuidas a Karpathy + license MIT). Más robusto que depender de descripciones de plugin que pueden dropearse.
• skill-bus (skill-bus-marketplace) — desinstalado. “Instalado pero no operativo por defecto” (sin subscriptions activas en el equipo); sus 10 skills duplicados global+project saturaban el listado.
• context-mode — desinstalado a project scope. Funcionalmente eliminado el 10-04-2026; el registro residual se purgó el 07-05-2026. setup-claude-code.ps1 lo sigue limpiando activamente por si reaparece.

2.6 Variables de entorno User

• BIB_MCP_TOKEN: token OAuth del MCP workspace. Edu genera uno distinto por persona y lo añade a la lista MCP_TOKENS del worker en Cloudflare. Lo pasa al dev por canal privado (Signal / 1Password).
• Se guarda con [Environment]::SetEnvironmentVariable("BIB_MCP_TOKEN", $value, "User").

2.7 Agentes Claude Code built-in

Por convención (Regla 10), general-purpose y Plan se lanzan con model: "opus".

3 · Parte transversal / compartida

3.1 Repo claude-method (C:\dev\claude-method)

3.2 Repo CreaRack-Pro (C:\dev\CreaRack-Pro)

• CLAUDE.md: instrucciones del proyecto, 24 reglas, stack, contexto de Biblioteca. Mantenido <40k chars.
• .claude/skills/: 5 skills bibliotecario CLI — bib-archive-last-answer, wiki-delete, wiki-lint-review, wiki-promote, wiki-review-drafts.
• context/agents/: contexto técnico profundo por módulo.
• context/RULES_DETAIL.md: ampliaciones de cada regla con historial.
• context/BIBLIOTECA.md: detalle del sistema Supercontexto.
• context/PATTERNS.md: patrones genéricos Django/PostgreSQL/seguridad.
• context/DESIGN_GUIDELINES.md: reglas UI obligatorias.
• .claude/bib-gate.json: marcador y configuración del gate de Biblioteca (report_url, skip_log_url). Las copias scripts/harness/ se retiraron el 05-08-2026: el pre-commit ejecuta los checks desde claude-method/harness/.

3.3 Repo CreaRackSL-workspace (C:\dev\CreaRackSL-workspace)

• CLAUDE.md del workspace: reglas específicas del hub.
• .claude/skills/: mismas 5 skills bibliotecario.
• public/supercontext/: STATE.md, LOG.md, DESIGN.md, AUDIT.md, briefings/NEXT.md. Regla 19.
• onboarding/shared-memory/: memorias específicas (infra, service accounts, Hetzner, Dokploy).
• src/content/wiki/: wiki en Markdown + frontmatter Supercontexto.
• functions/api/mcp/: código del MCP Worker.
• .github/workflows/: 5 crons del Bibliotecario.

3.4 MCPs registrados

setup-claude-code.ps1 Step 5 registra 2 MCPs en ~/.claude.json con scope user:

MCP workspace · familias de tools

D1 databases detrás: grafo + Archivo Maestro (embeddings bge-m3 1024-dim) + wiki Supercontexto + eventos.

3.5 Bibliotecario (crons autónomos)

5 workflows en CreaRackSL-workspace/.github/workflows/ corriendo como GitHub Actions cloud:

3.6 Hot cache (workspace.crearack.com/api/biblioteca/hot)

Endpoint del worker que devuelve snapshot del estado del grafo + actividad + alertas. hot-cache-sync.ps1 se ejecuta en hook SessionStart y descarga ese snapshot a project_hot_cache.md. Cada sesión arranca “caliente”.

3.7 Auto-sync claude-method (s60, 13-05-2026)

Flow del 4º hook SessionStart añadido en s60 para cerrar Gap 1 del propagador:

SessionStart hook 4
  └── pwsh -NoProfile -Command "try { & 'C:/dev/claude-method/harness/claude-method-sync.ps1' -SkipHook -SkipMemory } catch { ... }; exit 0"
       │
       └── claude-method-sync.ps1
            ├── 1. git pull --rebase origin main (en C:/dev/claude-method)
            │    └── si HEAD no cambió → "Ya estaba actualizado" + exit 0 (~150ms)
            ├── 2. SKIP hook reinstall              (-SkipHook)
            ├── 3. SKIP memorias compartidas       (-SkipMemory)
            ├── 4. global-agents/*.md cambiados    → copiar a ~/.claude/agents/  (overwrite)
            ├── 5. global-skills/<skill>/ cambiadas → copiar a ~/.claude/skills/ (overwrite)
            ├── 6. global-rules/*.md cambiadas     → copiar a ~/.claude/rules/   (overwrite · s82)
            ├── 6b. global-output-styles/*.md cambiados → copiar a ~/.claude/output-styles/ (overwrite · 14-08-2026)
            └── 7. global-settings/settings-base.json cambió → apply-claude-settings.ps1
                    (merge en ~/.claude/settings.json · preserva hooks + settings.local · s82)

Los pasos 4-7 solo actúan cuando esos archivos cambiaron en el pull (no en cada sesión). El paso 7 (s82) cierra el Gap 3 — antes settings.json solo lo escribía el setup en el onboarding; ahora un cambio de permisos/effort/ajustes Claude se propaga a los 3.

Qué resuelve: antes de s60, si Edu añadía un agente nuevo a claude-method/global-agents/ y hacía push, Dani y Txell NO lo recibían hasta ejecutar el sync manualmente. Tras s60, el sync se dispara solo al arrancar cada sesión Claude Code.

Coste: ~2-3s al arranque cuando el repo está al día.

Riesgo: conflict de rebase si dos miembros pushean simultáneamente. El wrapper try/catch + exit 0 silencia el error; el miembro afectado resuelve el rebase la próxima vez que pulle manualmente.

3.8 Promote local → central (s60, 13-05-2026)

Inverso del auto-sync. Script claude-method/harness/claude-method-promote.ps1 toma un agente o skill creado localmente en ~/.claude/{agents,skills} y lo asciende al método central + commit + push. Cierra Gap 2 del propagador.

~/.claude/agents/<name>.md          ──┐
                                       ├──→  claude-method-promote.ps1
~/.claude/skills/<name>/              ──┘            │
                                                     ├─ validate frontmatter (name + description)
                                                     ├─ detect: CREATE / UPDATE / IDENTICAL / ERROR
                                                     ├─ copy → claude-method/global-{agents,skills}/<name>
                                                     ├─ git pull --rebase + commit + push
                                                     └─ resumen
                                                              │
                                                              ▼
                            Dani/Txell · siguiente SessionStart · hook 4
                                                              │
                                                              ▼
                            ~/.claude/{agents,skills}/<name>  (copia automática)

Acciones detectadas:

• CREATE (destino no existe) → procede automático.
• UPDATE (destino existe + diverge) → aborta con exit 2; re-invocar con -Force para sobrescribir intencionalmente.
• IDENTICAL (hash igual) → no-op, exit 0.
• ERROR (source no existe / frontmatter inválido) → aborta con exit 1.

Validación de frontmatter obligatoria: name: + description:. Sin description, Claude nunca invoca el agente/skill.

Modos: -DryRun, -NoCommit, -NoPush, -Force (UPDATE).

Convención humana — el filtro que NO automatiza el script: antes de invocar, “¿esto es transversal — útil para los 3 miembros en cualquier proyecto — o solo del proyecto X?”. Si es del proyecto, vive en <repo>/.claude/skills/, NO aquí.

# Promover un agente nuevo
pwsh -NoProfile -File C:/dev/claude-method/harness/claude-method-promote.ps1 `
    -Type agent -Name mi-nuevo-agente

# Actualizar una skill ya promovida tras editarla localmente
pwsh ... -Type skill -Name design-wireframe -Force

# Ver qué pasaría sin tocar
pwsh ... -Type agent -Name mi-agente -DryRun

El propagador queda bidireccional:

• Forward (Gap 1): claude-method origin/main → ~/.claude/ via hook 4 auto-sync.
• Reverse (Gap 2): ~/.claude/ → claude-method origin/main via promote.
• Settings (Gap 3, s82): settings-base.json → ~/.claude/settings.json via apply-claude-settings.ps1 (merge defensivo).

3.9 Modelo de propagación — qué se sincroniza y qué no (s82)

Clave para entender el reparto equipo vs personal: recibir es automático (hook 4 al arrancar sesión), pero enviar al método central es un acto manual y deliberado — ese es el filtro de “¿esto es para los 3 o solo mío?”. No se sube nada solo; lo subes tú con promote (agents/skills) o editando el archivo base en claude-method (settings/rules/memorias).

Limitación honesta: MCP y plugins no se propagan solos. Un MCP nuevo es la única pieza del harness que sigue requiriendo acción manual por PC (por los tokens personales). Lo demás (skills, agents, rules, output styles, settings base) ya se mantiene vivo automáticamente.

Bootstrap del propio mecanismo: cuando se introduce un cambio en el script de sync, no aplica a la sesión en curso (PowerShell ya lo cargó) — surte efecto la siguiente. Por eso el rollout inicial del settings-sync (s82) requiere que cada uno corra apply-claude-settings.ps1 una vez; a partir de ahí, automático.

4 · Mapa operativo

Regla de oro: cualquier cambio que afecte al perfil del equipo (no a una sola persona) pasa por PR a claude-method + actualización de este documento + propagación a los 3 onboardings en el mismo commit.

Regla 24 / Regla 15 · igualdad de accesos del staff: el contenido transversal es idéntico para los 3. La excusa “X es el único que opera Y” NO es válida — si Y existe en el ecosistema, los 3 lo conocen y pueden ejecutarlo. El tono se adapta a cada perfil pero el alcance del acceso es el mismo.

5 · Onboarding Proxmox — procedimiento paso a paso

Ver [[ia-tech—metodo—lead-checklist]] para los pasos previos del lead, e [[ia-tech—metodo—onboarding-template]] para la plantilla del dev. Los onboardings personalizados:

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

6 · Evolución futura del perfil

6.1 VibeSec-Skill user-scope

Hoy se instala manualmente. Opciones: (a) versionarlo en claude-method/skills/; (b) dejarlo manual mientras solo lo use 1-2 personas. Recomendación: (a) cuando un segundo miembro del equipo lo necesite.

6.2 Plugins user-scope automatizados

Investigar si CLI de Claude Code soporta claude plugin install <name> no-interactivo. Si sí, añadir al bootstrap.

6.3 Repo dedicado .claude/skills/

Hoy las skills del equipo viven en .claude/skills/ dentro de los repos. Alternativa: repo separado CreaRackSL/claude-skills + submódulo. Decisión diferida hasta >10 skills compartidas.

6.4 Memorias específicas por persona vs por rol

Hoy el bootstrap copia las mismas memorias genéricas para los 3. Lo específico vive en el perfil que Claude construye con el tiempo. Alternativa: memorias iniciales por rol.

6.5 Sincronización de settings.json

Cada persona puede derivar su settings sin que los demás se enteren. Si emerge fricción, añadir diff check en SessionStart.

6.6 Monitoreo de schedules Bibliotecario

Verificar periódicamente que los 5 crons disparan automáticamente.

Changelog

Véase también

• [[ia-tech—metodo—claude-method-guide]]
• [[ia-tech—metodo—biblioteca-architecture]]
• [[ia-tech—metodo—quick-start]]
• [[ia-tech—metodo—lead-checklist]]
• [[ia-tech—metodo—runbook-cambios-harness]]
• [[crearack-tech—method—harness-guide]]
• [[crearack-tech—method—design-toolkit]]
• [[workspace—guias—team-processes]]
• [[workspace—onboarding—onboarding-edu]]
• [[workspace—onboarding—onboarding-dani]]
• [[workspace—onboarding—onboarding-txell]]