Reglas de trabajo
# REGLAS DE TRABAJO — Ecosistema SMART
_Leer completo antes de tocar cualquier cosa en este VPS._
Estas reglas las definió Yoy y son de cumplimiento estricto para
cualquier Claude que entre a trabajar en este servidor. No son
sugerencias — son la forma de trabajar acordada.
## 1. Validar, nunca asumir
Antes de decir "esto está roto" o "esto falta", verificar el estado
real del VPS con comandos. Si hay duda, preguntar antes de actuar.
## 2. No borrar ni modificar sin permiso explícito
Ningún archivo, carpeta, configuración o dato se borra o sobrescribe
sin que Yoy lo apruebe primero.
## 3. Todo en Python 3, ediciones quirúrgicas
Nada de nano. Nada de parches genéricos. Los cambios a código existente
se hacen con precisión (reemplazo exacto de la parte que cambia), no
reescribiendo archivos completos de una.
## 4. Archivos grandes: por fases/batches
Si un archivo es muy grande para un solo bloque, se divide en partes
que se van agregando (`cat >>` en vez de `cat >`), nunca se deja un
archivo gigante sin control.
## 5. Un bloque de código por respuesta
Para que Yoy pueda copiar, pegar y confirmar sin confundirse de cuál va
primero.
## 6. Cada script lleva encabezado obligatorio
Al inicio de todo script: para qué sirve, qué hace, y qué NO hace.
## 7. Cada script reporta su propio resultado
Con marcadores ✅/❌ en cada paso, y al final una sección clara que diga
OK con la salida para copiar — sin que Yoy tenga que volver a mandar el
bash completo para confirmar qué pasó.
## 8. Cada script declara su proyecto para el Historiador
Antes de correr algo nuevo, exportar `HISTORIADOR_PROYECTO=` en
la sesión (o dentro del script si aplica), así el Historiador lo
clasifica bien sin depender solo de en qué carpeta estás parado.
## 9. Consultar el Bodeguero antes de construir algo nuevo
Buscar si ese proyecto o función ya existió antes en algún Drive
indexado, pedir las carpetas específicas de ese proyecto, y revisar qué
ya funcionaba — para no reinventar ni adivinar desde cero.
## 10. Trabajar por fases, con checklist
Mantener claro qué ya se construyó y qué falta, fase por fase.
## 11. Generar "pasaporte" al cierre cuando se pida
Un documento con qué se creó, dónde, cómo, en qué fase quedó, y qué
falta pendiente — dejado dentro del propio proyecto como bitácora de
progreso, para que el próximo Claude lo lea solo sin que Yoy tenga que
volver a explicar todo.
## 12. Consultar las bitácoras de /var/historia// primero
Antes de proponer algo nuevo en un proyecto existente, leer su
BITACORA.md — ahí ya está registrado qué funcionó, qué no funcionó, y
por qué, generado automáticamente por el Historiador (Capa 1/2/3).
## 13. El pasaporte se actualiza siempre
Cada vez que se construye, modifica o cierra algo del ecosistema, el
pasaporte se actualiza en el momento — no solo cuando Yoy lo pide
explícitamente. Es responsabilidad del Claude que trabaja, no una
tarea aparte.
## 14. Todo proyecto nuevo nace en su propio Docker
Ningún proyecto nuevo se deja como proceso PM2 suelto compartiendo
entorno. Cada proyecto nuevo se construye desde el inicio dentro de su
propio contenedor Docker, aislado del resto.
Bitacora
## Configuración de entorno
_Actualizado: 2026-07-11 19:28_
- **A** ✅ — Verificar y configurar la variable HISTORIADOR_ACTIVO → Se exportó la variable HISTORIADOR_ACTIVO con valor 1
- **B** ✅ — Ejecutar script para registrar la historia de comandos → Se ejecutó el comando 'exec script' varias veces con diferentes parámetros
**Conclusion:** Se configuró el entorno y se ejecutó el script para registrar la historia de comandos, lo que permitió registrar los comandos ejecutados en la terminal.
---
## Cambio de directorio
_Actualizado: 2026-07-11 19:28_
- **A** ✅ — Cambiar al directorio /var/www/smartradio → Se utilizó el comando 'cd' para cambiar al directorio deseado
**Conclusion:** Se cambió al directorio /var/www/smartradio, probablemente para trabajar en el proyecto smartradio.
---