June 2026 statistics: sources, method and limitations

What do the homepage figures measure?

Singularity reports an internal Meteor Factory experience for June 8–14, 2026: 227 completed tickets, 86 non-bug tickets, 11 projects, a reported peak of 8 agents and 2.1 messages per ticket. These historical figures are not an independently audited benchmark, a customer average or a productivity guarantee. This case study was documented on October 10, 2026.

Sources and historical verification

Impacts commit 4a7f59ae230542ccfac4eb127fd76f3a60e2717c, dated June 21, 2026, attributes the figures to Singularity’s weekly report across 5 workspaces, with 227 completed tickets and 141 bugs. The year is reconstructed from that commit date. The remaining 86 tickets equal 227 − 141; describing all of them as features was too specific because the remainder may include documentation or refactoring.

The public Product Hunt listing, inspected on October 10, 2026, repeats these approximate figures in a cofounder’s comment. This is a publisher statement on a third-party platform, not independent validation.

The weekly report article explains the feature, but its screenshot and figures refer to a different report and do not validate this week. The technical reference inspected on October 10, 2026 is src/modules/gamification/main/domain/weekly-report-service.ts in Singularity. It aggregates local kanban_tasks, orchestration_runs, run_worktrees and task_feedback tables.

No frozen June database export, numerator/denominator for 2.1, or extraction timezone is retained in the website repository. We cannot recalculate or retrospectively certify these figures. The rules below describe the current implementation, not proof that June used identical filters.

What counts as a delivered ticket?

A delivered ticket means one unique ticket currently marked done, with done_at in the selected window. It does not independently prove production deployment, customer acceptance or defect-free code. Open, working, failed, cancelled and reopened but unfinished tickets are excluded. Reopening then completing a ticket assigns it to its latest completion window.

How can the calculation be reproduced privately?

Use a frozen, read-only copy of your own local database. Record the app version, extraction date and machine timezone. Weeks run from Monday midnight inclusive to the following Monday midnight exclusive. For the reported period, choose June 8, 2026 at 00:00 through June 15 at 00:00 in the recorded timezone; the historical timezone is unknown. Keep identifiers local for deduplication.

1. Tickets: select kanban_tasks with status = 'done' and start ≤ done_at < end. Count unique IDs; bugs have type = 'bug'. Non-bug tickets equal total minus bugs. Count type = 'feature' separately for actual features.
2. Projects: select runs where updated_at ≥ start and created_at < end. Count the distinct union of project-target target_id values and associated run_worktrees.project_id values. The scope is one local database, not all Singularity installations.
3. Peak: clamp run intervals to the week, discard empty intervals and compute maximum overlap, processing ends before starts at equal timestamps. This estimates simultaneous executions, not distinct AI providers or exact active CPU time.
4. Messages: select task_feedback rows where start ≤ created_at < end. Divide the row count by the number of distinct task_id values with a row. Stored replies and MCP results/questions count alongside prompts. Tickets with no messages are excluded. Round only the final display to one decimal. The denominator is not necessarily the completed-ticket count.

Keep the snapshot, calculation version and time bounds locally. Publish only aggregate ticket, bug, feature, distinct-project, peak, message and message-bearing-ticket counts. Never include customer names, ticket titles, identifiers, repository paths, prompts, replies or code in the public export. A missing table or column may trigger a fallback value in the service; mark such data unverified rather than claiming zero activity.

Limits of this internal case study

The historical editorial source reports 5 workspaces and 11 projects but does not retain their composition or exclusions of demonstration datasets. There is no control group, customer sample, complexity measurement or independent audit to establish a causal productivity gain. These are reported activity figures for one week. Read the ticket lifecycle and orchestration guide to evaluate the workflow on your own projects.