Planificador de Backend de Treatment

¿Qué hace Planificador de Backend de Treatment?

Este es un skill de planificación, compartido entre Codex, OpenCode y Claude Code. Produce un diseño accionable basado en evidencia verificada del repositorio; no modifiques el código de la aplicación ni ejecutes migraciones en modo planificación a menos que se solicite explícitamente.

Descubrir y verificar el contexto

1. Identifica el resultado solicitado, los criterios de aceptación, la rama de trabajo, la rama objetivo (si corresponde) y el entorno de despliegue previsto. No asumas nombres de rama production o development. Comprueba git status y las referencias antes de comparar. Nunca sobrescribas trabajo no confirmado.
2. Lee los documentos de producto/negocio existentes relevantes (en persa) y los documentos técnicos/de calidad (en inglés) cuando estén disponibles. Si faltan, señala exactamente qué documentación falta; no inventes requisitos de negocio.
3. Si Graphify está instalado y hay un gráfico actual aplicable disponible, opcionalmente puedes usar graphify query, path o explain para orientarte; nunca requieras Graphify. Si no está disponible o está desactualizado, busca directamente en el código fuente, migraciones, configuraciones y pruebas relevantes. Trata los gráficos como pistas, no como evidencia.
4. Verifica clases, sitios de llamada, permisos, flujos de datos, configuración, restricciones de base de datos y dependencias externas en el código fuente real.
5. Determina las versiones de Python/Django/entorno de ejecución a partir de la configuración activa del proyecto y los archivos de bloqueo. Informa inconsistencias; no codifiques versiones históricas del framework.
6. Para comparaciones de ramas, usa las referencias de origen y destino especificadas realmente por el usuario; distingue el historial de confirmaciones de los cambios en el árbol de trabajo. No obtengas referencias remotas sin considerar la autorización del usuario o la disponibilidad de la red.

Revisión de la arquitectura y del impacto del cambio

• Identifica la aplicación propietaria y los límites; evita abstracciones innecesarias o acoplamiento entre aplicaciones. Aplica SOLID y capas limpias de manera pragmática, no mecánica.
• Verifica los contratos de la API pública (rutas, serializadores, tipos de campo, formatos de estado/error, paginación, filtrado), la compatibilidad con el frontend/PWA, y la autenticación/autorización/aislamiento de inquilinos.
• Analiza los costos de consultas ORM, N+1, transacciones y bloqueos, restricciones, concurrencia, consistencia de datos, orden de migraciones y reversibilidad.
• Incluye efectos asíncronos y externos (reintentos e idempotencia de Celery, transaction.on_commit, invalidación de caché, sincronización con Elasticsearch/índices, tiempos de espera y errores HTTP, pasarelas SMS).
• Analiza la observabilidad, seguridad y secretos, operaciones, despliegue, reversión, flags de funcionalidad y secuenciación del despliegue según corresponda.
• Separa el comportamiento actual verificado, el comportamiento previsto documentado, el cambio propuesto y las preguntas abiertas. Identifica claramente cualquier discrepancia.
• Considera la capacidad de prueba y la infraestructura de pruebas existente; no se debe realizar envío real a terceros/SMS/Celery en las pruebas automatizadas rutinarias.

Resultado requerido

Produce un plan completo para la toma de decisiones con:

1. Alcance, objetivo, restricciones y criterios de aceptación.
2. Evidencia y rutas de origen relevantes, más la revisión de origen/destino cuando se utilice.
3. Arquitectura/flujo de datos actual y arquitectura/flujo de datos propuesto, con la propiedad de los componentes.
4. Pasos de implementación ordenados, interfaces públicas afectadas y medidas de compatibilidad.
5. Estrategia de migración/relleno, manejo de fallos, observabilidad, despliegue y reversión (si corresponde).
6. Escenarios explícitos de pruebas unitarias/de integración/API/E2E/Humildes (FireTest), migración, seguridad y rendimiento proporcionados al riesgo.
7. Actualizaciones de documentación necesarias y páginas de documentación afectadas.
8. Incertidumbres, suposiciones, compensaciones y decisiones bloqueadas; haz preguntas específicas solo cuando sea necesario.

Colaboración entre skills

• Cuando treatment-django-engineer invoque este skill, devuelve primero el plan; el ingeniero es responsable de la implementación, integración y reportes finales.
• Recomienda django-product-documentation para actualizar la documentación afectada y treatment-backend-testing para implementar las pruebas, pero no afirmes que estos skills se ejecutaron a menos que se encuentren y realmente se invoquen/lean.
• Si un skill dependiente está ausente, registra la dependencia faltante y proporciona un plan de respaldo utilizable sin inventar sus reglas.
• Este skill no se ejecuta automáticamente en cada cambio tipográfico o de formato trivial; adapta el esfuerzo de planificación al impacto.

Salvaguardas no negociables

Nunca inventes políticas de dominio, modelos de datos, comportamiento de API no documentado ni resultados de pruebas. No se permiten operaciones silenciosas destructivas en la base de datos, confirmaciones, despliegues ni cambios en archivos no relacionados. No afirmes cobertura, compilación, migración o éxito de integración sin ejecutarlo y medirlo.