Estatísticas de junho de 2026: fontes, método e limitações

O que os números da página inicial medem?

Singularity relata uma experiência interna do Meteor Factory de 8 a 14 de junho de 2026: 227 tickets concluídos, 86 tickets que não correspondem a bugs, 11 projetos, um pico relatado de 8 agentes e 2,1 mensagens por ticket. Estes números históricos não são uma referência auditada de forma independente, uma média do cliente ou uma garantia de produtividade. Este estudo de caso foi documentado em 10 de outubro de 2026.

Fontes e verificação histórica

Commit de Impacts 4a7f59ae230542ccfac4eb127fd76f3a60e2717c, datado de 21 de junho de 2026, atribui os números ao relatório semanal da Singularity em 5 espaços de trabalho, com 227 tickets concluídos e 141 bugs. O ano é reconstruído a partir dessa data do commit. Os 86 tickets restantes equivalem a 227 − 141; descrever todos eles como recursos era muito específico porque o restante pode incluir documentação ou refatoração.

A lista pública do Product Hunt, inspecionada em 10 de outubro de 2026, repete esses números aproximados no comentário de um cofundador. Esta é uma declaração do editor em uma plataforma de terceiros, e não uma validação independente.

O artigo do relatório semanal explica o recurso, mas a captura de tela e os números referem-se a um relatório diferente e não validam esta semana. A referência técnica inspecionada em 10 de outubro de 2026 é src/modules/gamification/main/domain/weekly-report-service.ts no Singularity. Ele agrega tabelas locais kanban_tasks, orchestration_runs, run_worktrees e task_feedback.

Nenhuma exportação congelada do banco de dados de junho, numerador/denominador para 2.1 ou fuso horário de extração é retida no repositório do site. Não podemos recalcular ou certificar retrospectivamente estes números. As regras abaixo descrevem a implementação atual e não provam que June usou filtros idênticos.

O que conta como ticket entregue?

Um ticket entregue significa um ticket único atualmente marcado como done, com done_at na janela selecionada. Ele não prova de forma independente a implantação da produção, a aceitação do cliente ou um código livre de defeitos. Tickets abertos, funcionando, com falha, cancelados e reabertos, mas inacabados são excluídos. Reabrir e concluir um ticket o atribui à última janela de conclusão.

Como o cálculo pode ser reproduzido de forma privada?

Use uma cópia congelada e somente leitura do seu próprio banco de dados local. Registre a versão do aplicativo, a data de extração e o fuso horário da máquina. As semanas vão da meia-noite de segunda-feira, inclusive, até a meia-noite da segunda-feira seguinte, exclusiva. Para o período relatado, escolha 8 de junho de 2026 às 00h00 até 15 de junho às 00h00 no fuso horário registrado; o fuso horário histórico é desconhecido. Mantenha os identificadores locais para desduplicação.

1. Tíquetes: selecione kanban_tasks com status = 'done' e start ≤ done_at < end. Contar IDs exclusivos; bugs têm type = 'bug'. Tickets sem bugs são iguais ao total menos bugs. Conte type = 'feature' separadamente para recursos reais.
2. Projetos: selecione execuções onde updated_at ≥ start e created_at < end. Conte a união distinta dos valores target_id do destino do projeto e dos valores run_worktrees.project_id associados. O escopo é um banco de dados local, não todas as instalações do Singularity.
3. Pico: limite os intervalos de execução à semana, descarte os intervalos vazios e calcule a sobreposição máxima, o processamento termina antes do início em carimbos de data/hora iguais. Isso estima execuções simultâneas, não provedores de IA distintos ou tempo exato de CPU ativa.
4. Mensagens: selecione linhas task_feedback onde start ≤ created_at < end. Divida a contagem de linhas pelo número de valores task_id distintos com uma linha. As respostas armazenadas e os resultados/perguntas do MCP contam junto com os prompts. Tickets sem mensagens são excluídos. Arredonde apenas a exibição final para uma casa decimal. O denominador não é necessariamente a contagem de tickets concluídos.

Mantenha o instantâneo, a versão do cálculo e os limites de tempo localmente. Publique apenas contagens agregadas de tickets, bugs, recursos, projetos distintos, pico, mensagens e tickets com mensagens. Nunca inclua nomes de clientes, títulos de tickets, identificadores, caminhos de repositório, prompts, respostas ou códigos na exportação pública. Uma tabela ou coluna ausente pode acionar um valor substituto no serviço; marque esses dados como não verificados em vez de afirmar que não houve atividade.

Limites deste estudo de caso interno

A fonte editorial histórica relata 5 espaços de trabalho e 11 projetos, mas não retém sua composição ou exclusões de conjuntos de dados de demonstração. Não há grupo de controle, amostra de clientes, medição de complexidade ou auditoria independente para estabelecer um ganho causal de produtividade. Estes são números de atividades relatados durante uma semana. Leia o ciclo de vida do ticket e o guia de orquestração para avaliar o fluxo de trabalho em seus próprios projetos.