43 Repos in 70 Days

At some point in late January 2026, something interesting happened. Governance and agent patterns started appearing in unrelated repos — repos that were built independently, at different times, solving different problems. By the time I ran the numbers in March, the word governance appeared as a meaningful concept in 15 out of 43 repos. The word agent in 12. Gatekeep in 15. Not because someone mandated it. Because the problems themselves converge toward those solutions.

This article is the data view of that convergence. Not opinion — measurements. Across 43 repos, 57,743 files, 3,424 meta documents, and 811 tracked commits, a pattern emerges that any CIO, CPO, or engineering leader building in this space needs to understand.

The Timeline

The build arc has five distinct phases. Each phase was a response to the limits of the previous one. None of them were planned upfront — they emerged from what the work demanded.

Phase	Dates	Repos	What emerged
Explore	Jan 8–17	6	Tool experiments — wallet-vote, guitar-tab, apex-ai, kiro-workspace. Establish what's possible. No architecture yet.
Govern	Jan 18–30	14	Governance as code crystallises. 7 gatekeep repos in a single week (Jan 24-25). The concept jumps from experiment to framework.
Agents	Jan 31–Feb 12	8	Execution layer emerges: Brood-Hive (distributed workers), LoopForge (state machine), gatekeep-trinity (multi-persona). Governance governs agents.
Platform	Feb 13–Mar 15	13	Org switch: personal org → ticketyboo-dev. Engine, OMNI, rooclaude, stack: assembly of components into coherent product.
Production	Mar 16–19	2	Paperclip (ops team platform). ticketyboo.dev (this site). Live infrastructure. Running agents.

The Governance Signal

The most striking data point is not the speed — it's the independent convergence. Governance patterns appeared in 15 out of 43 repos. Not 15 forks of the same concept. Fifteen separate repos, built at different times, for different purposes, all arriving at the same pattern: rules as code, personas as enforcers, approval gates as structured data.

The governance concept also appeared first — on January 9th, the second day of the build. Agent concepts arrived two days later. This ordering matters: it means the architecture was governance-first by instinct, not by retrofit.

The Build vs Configure Ratio

There's a philosophy baked into the gatekeep-trinity README that shapes everything here: "Buy don't build. Consume OSS. Scavenge what works." The claimed build:consume ratio is approximately 1:1000. The file anatomy of 57,743 files bears this out.

22% Python source code. 32% JSON configuration. 29% vendored dependencies (packages consumed, not built). Only 0.7% Terraform — yet the entire platform runs on AWS. This is what "buy don't build" looks like at the file level: most of the repo mass is consumed OSS and configuration, not original code.

The ~2,500 lines of net-new code built across the entire stack — the scanner layers, the governance engine, the API handlers — is not where the value lives. The value is in how those 2,500 lines compose the other 150,000. That ratio is a deliberate engineering philosophy, not an accident.

The Architecture That Emerged

When you look at the 43 repos not as a list but as a dependency graph, a layered architecture emerges that was never explicitly planned:

Each layer depends on the one below. The governance layer is not bolted on at the top — it sits below the agent layer. You cannot run an agent without passing through governance. That constraint was not designed; it was discovered by running agents without it and observing the consequences.

What the Data Doesn't Show

The DB has 811 commits across 43 repos — that's a cap of roughly 100 commits per repo from the initial ingest. The real commit volume is higher. Some repos were built almost entirely within 48-hour windows of intense agentic development: engine, OMNI, rooclaude were each substantially assembled in under a week.

The governance density metric (governance docs per repo) shows engine at 1,511 governance documents and agentic-stack-shared at 976. Those aren't docs written by hand — they're outputs of the governance system itself: scan results, compliance checks, decision records, persona consultation logs. The system generates evidence of its own operation.

The Org Switch Tells the Story

On February 13th, the first repo appeared under ticketyboo-dev rather than the personal org. That single data point marks the transition from exploration to production intent. Everything before that date was discovery. Everything after was assembly.

In the five weeks between February 13th and March 19th, thirteen repos were created under the ticketyboo-dev org. That's the platform layer: engine, OMNI, stack, paperclip, rooclaude, omni-whitelabel. Not experiments — components. The exploration phase had done its job.

What This Means Operationally

If you're a CTO evaluating whether this approach scales to an enterprise context, the meaningful data points are:

• Governance before agents: The pattern is empirically not optional. Every repo that runs autonomous behaviour has governance upstream of it. The 15/43 convergence number is a signal, not a coincidence.
• Config-dominant repos: 32% JSON means the team spends most time on configuration, not code. That's a feature — configuration is reviewable, diffable, and auditable in a way that runtime behaviour is not.
• Speed is a governance output: 43 repos in 70 days is not possible without a narrowed decision space. The governance layer constrains which choices are available, which makes every choice faster.
• The buy-not-build ratio is strategic: Building 2,500 lines to orchestrate 150,000+ lines of consumed OSS means the moat is not in the code — it's in the configuration, the personas, and the rules. Those are much harder to copy than code.

The platform is still being built. The data above is a snapshot at day 70. The next phase is inbound data — integrating the ghdev intelligence database into Metabase to get live dashboards across the full repo corpus. That's when the convergence story becomes a feedback loop: the platform analyses itself.