Hito · Harness/onboarding desplegado al 100% en los 3 perfiles del staff (s99)

Para todo el equipo (staff-share). Resumen del hito alcanzado el 31-05-2026 (sesión 99): el harness del equipo quedó desplegado e idéntico en las 3 máquinas, y la historia de por qué Dani y Txell estaban “a medias” — para que cualquiera lo reconozca si reaparece.

Qué se logró

El harness (la maquinaria que hace que Claude Code arranque con contexto, consulte la Biblioteca antes de actuar, respalde su memoria y cierre bien la sesión con “apaga”) quedó desplegado, idéntico y verificado en los 3 perfiles del staff: Edu, Dani y Txell.

Hasta hoy, solo el perfil de Edu estaba completo. Dani y Txell llevaban meses con el sistema medio instalado y “congelado” sin que nadie lo notara: sus Claudes se saltaban la Biblioteca y arrancaban con una versión vieja del método.

Por qué estaban “congelados” (3 causas encadenadas, todas en sus PCs)

1. dubious ownership (la gorda). Sus carpetas C:/dev/* pertenecían a otra cuenta de Windows distinta de la que arranca Claude. Git, por seguridad, se niega a operar sobre repos de otro dueño → el git pull automático de claude-method (en el arranque) fallaba en silencio → el método nunca se actualizaba. Arreglo: git config --global --add safe.directory C:/dev/<repo> (los 4 repos del equipo).
2. Python ausente. Los controles del harness son scripts de Python. Sin Python instalado, estaban registrados pero no se ejecutaban (“Python was not found”). Y un control que falla, Claude Code lo trata como “no bloqueante” → el guardián de la Biblioteca se colaba. Arreglo: winget install Python.Python.3.14 (la versión del proyecto).
3. Candado de effort heredado. Una directiva vieja (CLAUDE_CODE_EFFORT_LEVEL=xhigh) quedó pegada en su configuración local y no dejaba bajar el nivel de razonamiento a demanda. (El equipo pasó a control manual con /effort el 31-05.) Arreglo: quitar esa clave del settings.json local.

Por qué pasó desapercibido tanto tiempo: todos los fallos eran silenciosos (un git pull que falla y el sistema dice “todo al día”). Es el patrón que la Regla 15 prohíbe. Ahora hay una alarma: el sync GRITA si no puede actualizar claude-method, con la causa y el comando de arreglo.

Cómo comprobar que un perfil tiene el harness completo

Útil si entra un 4º miembro o si algo regresa. En PowerShell del perfil:

1. Check de hooks — los 6 deben dar [OK]: SessionStart (session-start.ps1), Stop (stop-worklog-reminder.ps1), gate Regla 0 en Pre/Post/UserPromptSubmit (bib_gate_check), y el hook del ritual (apaga_ritual_hook).
2. Prueba en vivo del gate: pedir crear un fichero como primer mensaje → debe bloquear con REGLA 0 NO CUMPLIDA.
3. Prueba del ritual: escribir apaga → debe arrancar el cierre (no responder solo “Hasta luego”).
4. Prueba del effort: /effort high → reiniciar → debe seguir en high.

Otros arreglos del mismo día (relacionados)

• Backup de memoria fiable: el repo claude-backups llevaba días sin actualizarse porque el backup se corría sin -PushGit (solo guardaba el .zip local). Ahora hay auto-backup diario con push real en el Stop hook + una guarda que impide que el backup se vacíe a sí mismo.
• Ritual “Apaga” determinista: un hook detecta “apaga” e inyecta el checklist del cierre en contexto, en vez de depender de que Claude lo recuerde de memoria.

Referencias

• Onboarding canónico (instalación desde 0): workspace--onboarding--setup-equipo-nuevo.
• Footgun reutilizable: memoria footguns_dubious_ownership_freezes_harness.
• Tareas: #78 (quitar candado effort), #79 (backup Dani), #80 (verificación harness Dani/Txell).

Última actualización: 31-05-2026 (s99).

Véase también

• [[workspace—onboarding—setup-equipo-nuevo]]
• [[workspace—onboarding—onboarding-txell]]