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 rclone y indexador
_Actualizado: 2026-07-11 21:39_
- **A** ✅ — Verificar remotes configurados en rclone → Se utilizaron comandos rclone listremotes y cat ~/.config/rclone/rclone.conf
- **B** ✅ — Crear script de indexación para el proyecto bodeguero → Se creó el script indexador.py en /root/bodeguero
**Conclusion:** Se configuró rclone y se creó un script de indexación para el proyecto bodeguero, permitiendo la interacción con los remotes y la indexación de archivos.
---
## Ejecución del indexador y consultas a la base de datos
_Actualizado: 2026-07-11 21:39_
- **A** ✅ — Ejecutar el script de indexación con diferentes remotes → Se ejecutó el script indexador.py con los remotes gdrive_personal y gdrive_smartmanager
- **B** ✅ — Realizar consultas a la base de datos de inventario → Se realizaron consultas a la base de datos para buscar archivos con nombres específicos
**Conclusion:** Se ejecutó el script de indexación con diferentes remotes y se realizaron consultas a la base de datos para buscar archivos, lo que permitió verificar la funcionalidad del indexador y la base de datos.
---
## Migración de registros de historial
_Actualizado: 2026-07-11 21:39_
- **A** ✅ — Crear script de migración para registros de historial → Se creó el script migrar_bodeguero.py para migrar registros de historial
- **B** ✅ — Ejecutar el script de migración → Se ejecutó el script migrar_bodeguero.py para migrar los registros de historial
**Conclusion:** Se creó y ejecutó un script de migración para registros de historial, lo que permitió trasladar los registros relevantes al proyecto bodeguero.
---