Depuración y Revisión de Agentes Astronómicos
Localiza los síntomas hasta el primer contrato fallido, repara la capa necesaria y luego demuestra por separado que la ejecución es correcta, que los mecanismos funcionan y que se obtienen beneficios reales. Las tres conclusiones se registran de manera independiente.
Este skill se extrae de materiales históricos legibles del proyecto "astronomical agent". Los casos son pistas de diagnóstico y no implican que la implementación actual tenga necesariamente los mismos defectos. Las cifras históricas (presupuestos, nodos, fechas, nombres de tarjetas y líneas de aprobación) no deben considerarse constantes por defecto para nuevas tareas.
Establecer Identidad
Confirma si el objetivo es corregir un error, diagnosticar, acelerar de manera equivalente, mejorar la estrategia o entregar una reparación. Identifica la ruta real y la versión actual; verifica CURRENT, la lista congelada, los recibos y el paquete final. La identidad se basa en el código fuente, las entradas, la configuración y los hashes de los resultados.
Registra la versión oficial del protocolo/evaluador, los campos visibles en línea, las restricciones de initialize, el modo de ejecución, la calibración de la CPU y los límites de tiempo de pared independientes. Solo cuando hay errores genéricos del sitio web o tarjetas locales con el mismo nombre, la causa raíz en la nube sigue sin localizarse.
Distingue entre: completo y válido, terminado por presupuesto, fallo técnico, interrupción del usuario, diagnóstico completo pero sin pasar la puerta de acceso científico. Algunas puntuaciones estacionales no entran en el ranking completo de la temporada; los valores faltantes se mantienen como null.
Leer Referencias Según el Síntoma
- Acción ilegal, inicio/ABI/manifest/ZIP, numeración de datos, limpieza de respaldos: lee protocol-and-data.md.
- Asignación alta pero puntuación baja, puntuación cero, omisión de corrección, omisiones REQ/solicitud, divergencia en reproducción: lee state-and-physics.md.
- Timeout, modelo sin beneficio, diagnóstico de aceleración que no cambia toda la temporada, fallo de exclusión/aceptación: lee budget-and-experiments.md.
- Consulta de contraejemplos históricos y evidencia de corrección: lee casebook.md.
- Verificación de identidad del archivo original: lee evidence.md y corpus-index.tsv.
Encontrar la Primera Divergencia
Compara según el flujo real de datos: entrada/restricciones → mensajes de consumo → estado/caché → entrada de candidatos → puntuación completa/asignación → acción final → ejecución oficial → liquidación de retroalimentación.
Encuentra la primera divergencia a partir del estado fallido mínimo o la trayectoria inmutable con la misma entrada. Guarda lo esperado, lo real, la unidad, el denominador, la selección de muestra y la fuente. Marca por separado la reproducción del código fuente, la asociación de logs, la hipótesis del mecanismo y la evidencia de beneficio.
Primero corrige la contaminación del protocolo, la identidad y la reproducción; luego explica las diferencias científicas. Una reproducción fiel (faithful replay) reproduce la secuencia original de consumo. Cambiar el comportamiento histórico es un nuevo candidato y no debe mezclarse con la trayectoria original. Cuando falten datos de inicialización o mensajes clave, detente en el límite identificable; no reconstruyas estados ocultos.
Diseñar Contrastes Mínimos Falsables
Una hipótesis se acompaña de una prueba que pueda refutarla. Síntesis de fixtures para verificar límites, shadow de estado público para verificar entrada y mecanismos de selección, pares completos de temporada para verificar el rendimiento global, y exclusión independiente para verificar la generalización limitada. Cada capa solo respalda las conclusiones de esa capa.
Enumera los elementos retenidos relevantes para esta ocasión: física/puntuación, información pública, RNG, orden de mensajes, ledger, ABI nativa, orden de candidatos/empates y facturación. Si una aceleración equivalente cambia la acción o el conjunto de candidatos, se reclasifica como un cambio de estrategia.
Los candidatos de estrategia primero rastrean si pueden entrar en la cadena de candidatos real, ser evaluados, cumplir la protección de finalización y cambiar la selección de ejecución. Si no se pasa la puerta del mecanismo predeterminado, se cierra esa hipótesis. Las correcciones de protocolo se verifican con contraejemplos de límites reales; no se fuerza a que las tarjetas normales cambien de acción.
Ejecutar Validación Limitada
La puntuación y los modelos remotos utilizan la autorización actual y el presupuesto limitado; no heredan los saldos restantes de investigaciones cerradas. Selecciona límites significativos, diferencias y controles normales según el cambio.
Cuando el proyecto use un registrador, antes de iniciar confirma que planned sea exitoso, lee la identidad de vuelta, los hashes de fuente/entrada y el aislamiento de salida. Si el registro falla, primero maneja el fallo. Las excepciones aún liquidan el costo real y el número de solicitudes en finally. Las correcciones técnicas usan una subversión que retiene la versión principal fallida. El registro posterior se marca como retrospective.
El código fuente final se compara con la misma fuente, la misma entrada y facturación OFF/ON. Después de un cambio de código fuente, solo se refiere a la evidencia que aún coincide con ese código fuente. Informa por ítem las puertas de acceso requeridas: estado final completo, presupuesto, REQ, solicitud, puntuación científica/total y los roles de API solicitados. Cualquier puerta obligatoria fallida significa que no se acepta.
Tras un fallo, pasa a una nueva hipótesis de causa raíz con nueva evidencia. Cambiar la semilla, elegir código fuente, modificar la línea de aprobación o ampliar el escaneo no es una reparación válida de la aceptación original. El conjunto de exclusión utilizado para selección o diagnóstico se convierte en datos de desarrollo; la generalización posterior usa una nueva exclusión.
Criterios de Salida y Finalización
Según la magnitud del problema, genera:
Síntoma y primer enlace fallido:
Nivel de evidencia e identidad de la fuente:
Causa raíz confirmada / pendiente de confirmación:
Cambio mínimo y elementos retenidos:
Resultado: Protocolo / Estado / Mecanismo / Temporada completa / Exclusión / Despliegue
Fallos, elementos no ejecutados e incertidumbres:
Próxima prueba mínima que puede diferenciar la hipótesis:
El paquete cargado se genera desde el código fuente congelado final, en un directorio nuevo, usando el analizador oficial de manifest para build/run. Verifica los hashes de JSONL, recursos y source/ZIP. Informa por separado para: mock, native local, API real, Linux y sitio web; no se sustituyen entre sí.
Las nuevas experiencias deben incluir condiciones de aplicabilidad, reproducción mínima y evidencia; solo se retienen las reglas que realmente cambian decisiones.