Lead checklist antes del onboarding

Checklist del lead — antes de onboardear a un dev nuevo

Este checklist es para el responsable del proyecto (Edu). Todo lo que aquí se configura queda en servicios externos (GitHub, Cloudflare) que el onboardee NO puede tocar por sí mismo.

1. Accesos de repositorios (GitHub)

Invitar al nuevo dev como colaborador en:

CreaRackSL/CreaRack-Pro — Write (o Admin si va a gestionar la rama main).
CreaRackSL/CreaRackSL-workspace — Write.
CreaRackSL/claude-method — Read. Lectura basta: solo clonan para tener el harness y las memorias genéricas. Nunca escriben aquí salvo que propongan mejoras al método.

Ir a https://github.com/orgs/CreaRackSL/people y añadirles.

2. Token Bearer MCP personal

Cada dev debe tener su propio token Bearer. NO reutilizar el tuyo. Eso permite identificar quién hace qué en /biblioteca/pulse (actor en activity_log) y revocar acceso individual si hace falta.

Pasos:

Generar un token aleatorio fuerte (ej. openssl rand -hex 32 en WSL, o [guid]::NewGuid().ToString("N") dos veces concatenado en PowerShell).
Añadirlo al secret MCP_TOKENS de Cloudflare Pages del workspace. Formato: <usuario>:<token>,<usuario2>:<token2>,...
- Dashboard CF → Pages → workspace project → Settings → Environment variables → Edit variables → MCP_TOKENS.
- Recuerda: los cambios de env vars en CF solo se aplican en el SIGUIENTE deploy (footgun conocido). Forzar un redeploy tras editar.
Pasarle el token al dev por canal privado (Signal, 1Password shared vault). Nunca por email ni en el repo.

3. Secret GitHub Actions (solo workspace)

Para que el cron diario de drift funcione, el repo CreaRackSL-workspace necesita el secret:

MCP_TOKEN → uno de los tokens Bearer válidos (puede ser uno específico tipo cron:<token> o reutilizar el tuyo).
- Dashboard GitHub → Settings → Secrets and variables → Actions → New repository secret.
DRIFT_DRY_RUN (variable, no secret) → 1 durante los primeros días de rodaje. Cambiarlo a 0 cuando quieras que empiece a generar alertas reales.
- Settings → Secrets and variables → Actions → Variables tab → New repository variable.

Primera ejecución manual recomendada (para validar sin esperar al cron):

GitHub → Actions → “Escriba drift cron” → Run workflow → dry_run=1.

4. Preparar el documento de onboarding personalizado

Copiar claude-method/onboarding/onboarding-template.md a un nuevo archivo con los placeholders rellenados:

Placeholder	Valor típico
`{{DEV_NAME}}`	`Dani`, `Txell`
`{{DEV_NAME_LOWER}}`	`dani`, `txell`
`{{PROJECT_NAME}}`	`CreaRack-Pro`
`{{WORKSPACE_NAME}}`	`CreaRackSL-workspace`
`{{ORG}}`	`CreaRackSL`
`{{REPO_URL}}`	`https://github.com/CreaRackSL/CreaRack-Pro.git`
`{{WORKSPACE_URL}}`	`https://github.com/CreaRackSL/CreaRackSL-workspace.git`
`{{DEV_ROLE}}`	`Dev`, `COO`
`{{DATE}}`	Fecha de hoy
`{{START_CMD}}`	`docker compose up -d`
`{{DEV_URL}}`	`http://localhost:8000`
`{{TEST_CMD}}`	`docker compose exec web pytest`
`{{MCP_NAME}}`	`workspace`

Enviarlo al dev junto con el token Bearer por canal privado.

5. Primer smoke test con el dev

Estar disponible en la primera sesión para validar:

claude mcp list muestra workspace: Connected.
/memory en Claude Code lista las memorias genericas (footguns_*, feedback_*) y al menos el user_profile.md.
project_hot_cache.md se creó tras la primera sesión (prueba que BIB_MCP_TOKEN quedó guardado y el hook SessionStart 2 funciona).
(s60) Hook 4 SessionStart claude-method auto-sync se dispara — al arrancar Claude Code aparece “claude-method sync · Ya estaba actualizado” o el changelog sync <abc> → <def> en el output inicial. Si no aparece, revisar que ~/.claude/settings.json tenga el 4º elemento en hooks.SessionStart[0].hooks.
(s60) ~/.claude/agents/design-collaborator.md y ~/.claude/skills/design-*/SKILL.md × 14 presentes tras la primera sesión (propagados por hook 4 o por setup paso 4c).
Commit de prueba — modificar un archivo .py/.ts de una app conocida, ejecutar bib_report_change vía MCP, y hacer git commit. El hook debe pasar en verde.

6. Si algo no encaja

Re-ejecutar setup-claude-code.ps1 es seguro: hace backup del settings.json antes de tocarlo y las memorias se sobrescriben con las versiones de claude-method (las personalizaciones posteriores del dev se mantienen si se corre claude-method-sync.ps1 luego, no el setup completo). (s60) Re-ejecutar regenera el settings.json con los 4 hooks SessionStart actuales. Devs con onboarding pre-s60 tienen solo 3 hooks; pueden añadir el 4º a mano (ver setup-claude-code.ps1 líneas ~108-130) o re-ejecutar el setup.
Promote inverso (s60) — si un dev creó un agente/skill local que quiere compartir con el staff: pwsh C:/dev/claude-method/harness/claude-method-promote.ps1 -Type {agent|skill} -Name <slug>. Detecta CREATE/UPDATE/IDENTICAL automáticamente, valida frontmatter, commit + push directo a claude-method/main. Los demás reciben en su próxima sesión via el 4º hook auto-sync. Preguntar al lead antes de promover si hay duda sobre si es transversal o solo del proyecto.
Si claude mcp list no conecta tras OAuth, revisar que la app de Cloudflare Access permite el email del dev.
Si el token Bearer no funciona: curl.exe -s https://workspace.crearack.com/api/mcp/health debe responder 200. El token se valida comparando con MCP_TOKENS env var, así que un error 401 significa que el token que le diste al dev no está en esa variable o el deploy no tiene la versión actualizada.

Véase también

[[ia-tech—metodo—onboarding-template]]
[[ia-tech—metodo—quick-start]]
[[ia-tech—metodo—claude-method-guide]]
[[feature—method—onboarding-v2]]
[[workspace—onboarding—onboarding-edu]]