Estadísticas de junio de 2026: fuentes, método y limitaciones

¿Qué miden las cifras de la página de inicio?

Singularity informa una experiencia interna de Meteor Factory del 8 al 14 de junio de 2026: 227 tickets completados, 86 tickets que no corresponden a errores, 11 proyectos, un pico informado de 8 agentes y 2,1 mensajes por ticket. Estas cifras históricas no son un punto de referencia auditado de forma independiente, ni un promedio de clientes ni una garantía de productividad. Este estudio de caso se documentó el 10 de octubre de 2026.

Fuentes y verificación histórica

Commit de Impacts 4a7f59ae230542ccfac4eb127fd76f3a60e2717c, con fecha del 21 de junio de 2026, atribuye las cifras al informe semanal de Singularity en 5 espacios de trabajo, con 227 tickets completados y 141 errores. El año se reconstruye a partir de esa fecha del commit. Los 86 tickets restantes equivalen a 227 − 141; describirlos todos como características era demasiado específico porque el resto puede incluir documentación o refactorización.

El listado público de Product Hunt, inspeccionado el 10 de octubre de 2026, repite estas cifras aproximadas en el comentario de un cofundador. Esta es una declaración del editor en una plataforma de terceros, no una validación independiente.

El artículo del informe semanal explica la función, pero su captura de pantalla y sus cifras hacen referencia a un informe diferente y no validan esta semana. La referencia técnica inspeccionada el 10 de octubre de 2026 es src/modules/gamification/main/domain/weekly-report-service.ts en Singularity. Agrega tablas locales kanban_tasks, orchestration_runs, run_worktrees y task_feedback.

En el repositorio del sitio web no se conserva ninguna exportación congelada de la base de datos de junio, ni el numerador/denominador de 2.1 ni la zona horaria de extracción. No podemos recalcular ni certificar retrospectivamente estas cifras. Las reglas siguientes describen la implementación actual, no prueban que June haya utilizado filtros idénticos.

¿Qué cuenta como ticket entregado?

Un ticket entregado significa un ticket único actualmente marcado como done, con done_at en la ventana seleccionada. No prueba de forma independiente la implementación de producción, la aceptación del cliente o el código libre de defectos. Se excluyen los tickets abiertos, en funcionamiento, fallidos, cancelados y reabiertos pero sin terminar. Reabrir y luego completar un ticket lo asigna a su última ventana de finalización.

¿Cómo se puede reproducir el cálculo de forma privada?

Utilice una copia congelada de solo lectura de su propia base de datos local. Registre la versión de la aplicación, la fecha de extracción y la zona horaria de la máquina. Las semanas van desde el lunes a medianoche inclusive hasta el lunes siguiente a medianoche exclusivo. Para el período informado, elija del 8 de junio de 2026 a las 00:00 al 15 de junio a las 00:00 en la zona horaria registrada; se desconoce la zona horaria histórica. Mantenga los identificadores locales para la deduplicación.

1. Tickets: seleccione kanban_tasks con status = 'done' y start ≤ done_at < end. Cuente identificaciones únicas; los errores tienen type = 'bug'. Los tickets sin errores equivalen al total menos los errores. Cuente type = 'feature' por separado para las características reales.
2. Proyectos: seleccione ejecuciones donde updated_at ≥ start y created_at < end. Cuente la unión distinta de los valores target_id del objetivo del proyecto y los valores run_worktrees.project_id asociados. El alcance es una base de datos local, no todas las instalaciones de Singularity.
3. Pico: fije los intervalos de ejecución a la semana, descarte los intervalos vacíos y calcule la superposición máxima; el procesamiento finaliza antes de comenzar en marcas de tiempo iguales. Esto estima ejecuciones simultáneas, no distintos proveedores de IA ni tiempo exacto de CPU activa.
4. Mensajes: seleccione las filas task_feedback donde start ≤ created_at < end. Divida el recuento de filas por el número de valores task_id distintos con una fila. Las respuestas almacenadas y los resultados/preguntas de MCP cuentan junto con las indicaciones. Se excluyen los tickets sin mensajes. Redondee sólo la visualización final a un decimal. El denominador no es necesariamente el recuento de tickets completados.

Conserve la instantánea, la versión del cálculo y los límites de tiempo localmente. Publique solo recuentos agregados de tickets, errores, funciones, proyectos distintos, picos, mensajes y tickets con mensajes. Nunca incluya nombres de clientes, títulos de tickets, identificadores, rutas de repositorio, mensajes, respuestas o códigos en la exportación pública. Una tabla o columna faltante puede activar un valor alternativo en el servicio; marque dichos datos como no verificados en lugar de afirmar que no hay actividad.

Límites de este estudio de caso interno

La fuente editorial histórica informa 5 espacios de trabajo y 11 proyectos, pero no conserva su composición ni exclusiones de conjuntos de datos de demostración. No existe un grupo de control, una muestra de clientes, una medición de la complejidad o una auditoría independiente para establecer una ganancia de productividad causal. Estas son las cifras de actividad reportadas durante una semana. Lea el ciclo de vida de los tickets y la guía de orquestación para evaluar el flujo de trabajo en sus propios proyectos.