Collaborative Development Across Large Repo Fleets

A local-first agentic console that is fully useful for one developer, and whose value compounds superlinearly with repos × teammates because the durable memory is shared while the working planes are private. The two-plane architecture (ADR-011) is what makes solo-first and team-scale the same product.

Thesis

1. Ozzy Dev is fully useful for a single developer on day one: instant, accurate knowledge of everything they have checked out, safe verified writes, a signed receipt for every operation, all local.
2. As the codebase grows past what one developer can hold in their head, and as teammates arrive, the SAME product compounds: the durable memory (secrets, receipts, telemetry, experiments, workspace inventory) is already a shared team database — no new install, no new tool category.
3. The mechanical reason this works is a hard architectural split between shared team memory (Cloudflare D1) and per-workspace local tool planes (indexing, search, write routing, symbol servers). One is deliberately cross-machine; the other is deliberately isolated. Neither leaks into the other.
4. Value scales with repos × teammates, not just teammates. A solo dev with 45 repos already sees the compounding — receipts from yesterday sharpen the router today. Add teammates and the same telemetry sharpens across the fleet.

The two-plane architecture (ADR-011)

The boundary between what is deliberately shared and what is deliberately isolated is the load-bearing decision. It sits at exactly one place: memory that outlives a workspace lives on the shared plane; tooling that operates on the working tree lives on the local plane.

Shared team plane (Cloudflare D1)

One D1 per team, deliberately cross-workspace and cross-machine.

• Encrypted secrets vault (ADR-006 Amendment 2 — AES-256-GCM envelopes, verify-live-on-save, apply-time 0600 files).
• Workspace registry — every workspace onboarded on any machine posts a row.
• Repos-per-workspace inventory (candidate `workspace_repos` rollup, ADR-011 Consequences).
• Receipts (ADR-009) — signed record of every search and every write.
• Telemetry — session_reports, tool_benchmark_events, batched via `telemetry_emit`.
• Experiments — paper_slug-keyed rows: rounds, variants, decisions.

Why here: Durable. Portable across developers and machines. Cheap enough at the row rates a small team generates. Cloudflare-managed encryption at rest, OAuth-scoped operator access, audit-log allowlist — the ADR-006 compensating-controls stack applies uniformly regardless of who is writing.

Per-workspace local plane

One instance per workspace root, on the developer's machine. Sees exactly the git repos under that root and nothing else.

• codesearch registry + `nexartis` group + serve daemon — via `$WORKSPACE/.codesearch/repos.json` and `CODESEARCH_REPOS_CONFIG`.
• Serena serve daemon — one LaunchAgent per workspace, slug-labelled label, deterministic port.
• ChunkHound index (paused per D4) and its config.
• Zilliz semantic corpus collections — path-keyed per repo.
• `ozzydev-write` and `ozzydev-search` MCPs — spawn-CWD-bounded to the workspace root.
• `kilo.json` / `.cursor/mcp.json` — workspace-driven expert URLs.

Why here: Latency, freshness, and privacy. An index has to see the checked-out working tree to be honest; a symbol server has to run beside the LSP; a fast-apply model has to write to the local filesystem. All of these want the current developer's local state as their ground truth — not another workspace's, not another machine's.

Why the boundary sits exactly there

1. Memory that OUTLIVES a workspace goes on the shared plane. Anything a teammate might reasonably need three months from now — a receipt, a verified secret, a benchmark result — is D1. Ephemeral local artifacts stay local.
2. Memory that is EXPENSIVE TO REBUILD goes on the shared plane. Vault verification round-trips, telemetry batches, receipt signatures — you would not want to redo any of these on machine restore.
3. Tooling that operates ON the working tree stays local. Indexers, watchers, LSP servers, apply/verify pipelines all have latency budgets that a network hop would blow.
4. Nothing gets defense-in-depth'd across the boundary. The write router does not silently fall back from local to D1; the search router does not silently degrade from workspace to fleet. Each side fails loud and classified (workspace §2 no-hidden-behavior rule).

Roll-forward workspaces

The local plane is disposable by design. Onboarding is install.sh; retirement reverses it; the shared D1 remembers what happened either way.

1. Workspaces are ephemeral and plural per developer. A machine hosts several at once — one for the current release, one for a spike, one for a long-lived refactor.
2. Onboarding a workspace: `install.sh` clones the chosen repos into `$WORKSPACE`, exports `CODESEARCH_REPOS_CONFIG=$WORKSPACE/.codesearch/repos.json`, provisions the per-workspace codesearch + Serena serve LaunchAgents, and POSTs the workspace + repo inventory to the shared D1. Cheap enough to do daily.
3. Retiring a workspace: `install.sh --retire` boots out the LaunchAgents, removes the local `.codesearch/`, `.serena/`, `.chunkhound/` artifacts, and marks the workspace retired in D1. The receipts and telemetry the workspace produced are unchanged.
4. Configuration drift is impossible by construction. Each new workspace is a clean local plane bootstrapped from the same `mcp/registry.json` + `install.sh` — the shared D1 remembers what the workspace contained, not how it was configured.

Team-scale mechanics that fall out for free

Nothing in this section is a new subsystem — each item is what the two-plane split already enables when a second developer joins the team.

• One-key onboarding — A new teammate installs Ozzy Dev, points at the team D1, imports one vault key, and every integration lights up — Voyage embeddings, Context7 docs, Cloudflare tunnel, GitHub, Linear. ADR-006 Amendment 2's verify-live-on-save gate covers rotation. The RC1 release notes call this out as the team-adoption path.
• Cross-dev workspace visibility — The workspace registry in D1 answers "who has which repo checked out where?" — the console `/memory` Repos tab already renders per-workspace coverage against the shared inventory. Coordination overhead that git alone does not surface.
• Receipts as shared reputation — Every routed search (`ozzydev-search`) and every routed write (`ozzydev-write`) emits a signed receipt keyed by workspaceId. The team-wide receipt trail is the raw material for the KYM continuous-learning loop (Dogfood RC1 §Roadmap): agent performance measured across the whole team, not just one developer.
• Telemetry keyed by workspace — Session reports and tool benchmark events already carry workspaceId. Cross-dev aggregation is a group-by query — no schema change needed to answer "which write category is slowest across the fleet?".
• Fleet-wide research log — The console `/research` pages are the durable knowledge base; every tooling change or benchmark updates the affected page. A teammate joining the team inherits every conclusion with citations, not a Slack archaeology dig.
• Cross-dev experiment aggregation — Experiments key on `paper_slug`; variants and rounds accumulate across whoever ran them. A bakeoff that would take one developer a week is a matter of days when three teammates contribute rounds in parallel from their own workspaces.

Scaling dimensions & open questions

• Repo count
  Today: 45 active repos across the Nexartis fleet (Dogfood RC1). The largest single workspace on the operator's machine holds all 45.
  Open: At what repo count does the codesearch registry rebuild become slow enough that per-workspace scoping is a latency win rather than just an isolation win? Waves W1–W5 will produce the first numbers.
• Concurrent workspaces per machine
  Today: 3 concurrent workspaces measured on the operator's Mac (~2 daemons each ≈ 6 processes). fd/memory budgets fine under launchd caps at this scale.
  Open: The daemon budget under 8+ concurrent workspaces on a laptop-class machine. Whether workspace hibernation (idle workspaces stop their serves, resume on activity) becomes necessary before that ceiling.
• Team size
  Today: One operator dogfooding. Team onboarding is the RC1 Next horizon.
  Open: D1 write contention at N=10, N=30, N=100 developers — with the row cadence receipts + telemetry generate. Secrets rotation ergonomics when many teammates share one vault (ADR-006 Amendment 2 covers the crypto; the ops question is who rotates when).
• Experiment throughput
  Today: Bakeoffs run by one developer per paper_slug.
  Open: Cross-dev variant scheduling — should the harness distribute rounds automatically, or is opt-in per teammate the right default? Bandit sampling under contributor bias (some devs run more rounds than others) is the honest statistical question.

Prior art

Five neighborhoods of related work. Ozzy Dev is not the first system to notice that AI coding agents change the cost of not having a shared team knowledge layer — but it makes a specific set of choices that no cited entry combines.

Monorepo tooling at scale

• Google — Piper + CitC (Potvin & Levenberg, CACM 2016): 1B files, 86 TB, one repository, custom VCS + FUSE workspaces + CodeSearch + Critique + Tricorder. The reference existence proof that "one repository" is workable at extreme scale IF you pay the tooling cost.
• Meta — Sapling + EdenFS + Buck2: virtual filesystem loads only the files the developer touches; scaling optimization happens at the filesystem layer, not the version-control layer.
• Block, Uber, Microsoft 1JS: real-world multi-quarter migrations documenting that "copy Google's structure" does not translate to Google-scale tooling investment.

Position: The monorepo camp's answer to "how do I see everything at once?" is: put everything in one repository and invest in tooling. Ozzy Dev's answer for polyrepo teams is: keep the repos separate, but give the AGENT a per-workspace view of exactly the subset in play plus a shared team memory that outlives any workspace.

Meta-repo / virtual-monorepo pattern

• `mateodelnorte/meta` (npm): the original "tool for turning many repos into one" — a metarepo tracks references, plugins wrap common commands.
• The Dev Newsletter, "The Meta-Repo Pattern" (2026-03-30): AI coding agents reopen the mono-vs-poly debate — teams build lightweight repositories above their code containing only documentation, manifests, and agent configuration so a stateless agent can orient itself across a system.

Position: The meta-repo pattern IS a partial answer to our problem — but it puts the map inside git, at the granularity of files. Our workspace is the runtime equivalent: not a checked-in map but a live-indexed subset, refreshed with every clone, discarded on retire.

Multi-repo AI orchestrators

• Sourcegraph Amp — the Librarian sub-agent searches across repositories, threads persist in the cloud, model routing is automatic. Proprietary, cloud-required, enterprise-priced.
• Codex CLI — local-first, open-source, single-repo today; multi-repo is an open feature request.

Position: Amp shows the shape of the demand — team-scale, cross-repo, receipt-visible agent work. Its answer is "put the compute in our cloud." Our answer is: put the compute on the developer's machine (local plane) and put the memory in the team's D1 (shared plane). Different tradeoff, same shape of value.

Cloud development environments

• GitHub Codespaces, Gitpod / Ona, Coder, Daytona, DevPod: `devcontainer.json` is the de facto 2026 standard. Consistent environments, faster onboarding, workspaces persist in the cloud.
• The trade-offs (freeCodeCamp, HackerNoon, saascompared 2026 comparisons): usage-based cost, network latency, vendor lock-in for hosted compute.

Position: CDEs solve "my machine is different from yours." That is not our problem — we already normalize via `bootstrap.sh` + `install.sh` on each developer's Mac. What CDEs do NOT solve is durable cross-session agent memory across developers; that is our layer.

Team memory for AI coding agents (2025–2026 SOTA)

• Egregore (Show HN 2026-04-18) — git-backed shared cognition for Claude Code: branching for isolation, merging for reconciliation, PRs for review of agent memory itself.
• `zero8dotdev/smriti` — shared memory for AI-powered engineering teams, indexes conversations across Claude Code / Cursor / Codex, git as the transport.
• ContextForge — project-scoped semantic memory MCP; team-shared knowledge invited per project.
• `lktiep/cortex-hub` — self-hosted AI agent memory + code intelligence, hierarchical memory + team knowledge base with temporal validity + supersession chains.
• `xChuCx/agent-memory` — markdown source-of-truth memory with a git merge driver and federation of pinned read-only "landscape" stores.
• Mozilla.ai `cq exchange` — private-namespace + public-commons for reusable Knowledge Units, hosted.

Position: This is the closest neighborhood. Every entry answers "how does agent memory outlive one session, one dev, or one machine?" — with git, with SQLite, with a cloud service, with markdown. Ozzy Dev's specific choice: D1 as the shared substrate (already the persistence baseline per ADR-006), receipts as the primary evidence type (not conversations, not knowledge units), and a hard workspace/repo isolation boundary on the local plane.

What we do differently

1. We do not share COMPUTE. Every developer runs their own local plane, indexes their own working trees, gets sub-second search and write latency.
2. We do share MEMORY. Every receipt, every telemetry event, every experiment round, every verified secret lives in the team D1 that any teammate can query.
3. The unit of shared memory is the receipt, not the conversation. Receipts are structured, signed, and machine-consumable — what the KYM continuous-learning loop needs to score agents, not what a human needs to read.
4. The unit of local scope is the workspace, not the repo or the machine. A repo can appear in three teammates' workspaces at once with three different indexes and no interference — because each workspace's local plane is scoped by construction (ADR-011).

Open questions

• D1 write contention under team load — Receipts + telemetry write cadence at N devs × M workspaces × K sessions/day. The compensating-controls stack (ADR-006 Am. 2) assumes single-tenant per D1; the row rate under a full team is unmeasured.
• Vault key rotation ergonomics at team scale — ADR-006 covers the crypto. The ops question — who initiates rotation, how the team-wide re-apply propagates, how a lost master key on one developer's Mac is handled — remains an operational design question.
• What the FIRST team-visible dashboard should be — The console `/memory` Repos tab renders per-workspace coverage today. The first cross-dev view (who is touching what right now? which paper_slug is anyone actively running rounds against?) is a UX question with immediate impact on collaboration behavior.
• Contributor-biased experiment aggregation — When Alice runs 200 rounds and Bob runs 20, the bandit's posterior gets Alice-weighted answers unless the harness accounts for contributor variance. Statistical honesty question, not a schema question.
• Retirement policy for D1 rows tied to retired workspaces — A retired workspace's local artifacts are gone; its receipts and telemetry rows are not. Whether they age out on a schedule, roll up into workspace summaries, or persist forever is a data-lifecycle decision (ADR-006 Am. 2 directive "all data lifecycle in D1").

Roadmap

• Now (waves W1–W5, ~2.5 days) — The ADR-011 refactor: per-workspace `CODESEARCH_REPOS_CONFIG`, per-workspace codesearch + Serena serve LaunchAgents, workspace-driven expert URLs, router-side workspace filter (belt-and-suspenders), workspace-retire path.
• Next (candidate follow-up, out of W1–W5) — `workspace_repos` D1 rollup table so the console Repos tab stops shelling into machine-local registries — enables cross-dev visibility of who has what checked out (ADR-011 Consequences).
• Team-adoption horizon (RC1 Next per dogfood notes) — Second developer onboarding on Kilo or Cursor. One-key vault handshake. First cross-dev receipt aggregation queries. First team-visible dashboard tile in the console.
• Later (operator: "other team functionality once we stabilize the baseline") — Team-scale features that ride on the two-plane substrate: cross-dev experiment scheduling, workspace hand-off (Alice retires, Bob picks up the same repo set), team-visible research-page contributions, receipt-scored per-developer feedback loops. Explicitly deferred until the baseline holds.

How this page stays current

Living draft. v0.1 lands the two-plane thesis, the ADR-011 architecture, prior art, and open questions. Later revisions incorporate W1–W5 measured latency + fd/memory numbers; the first second-developer onboarding trace; the first cross-dev receipt-aggregation query; and the first team-visible dashboard tile in the console. Numbers replace claims as they arrive; the version at the top bumps on every material change.