Building for scale: how JuhJuh handles multi-repo orchestration

Coordinating changes across multiple repositories is one of engineering's hardest problems. A feature that touches your API, your frontend, and a shared library requires three separate branches, three PRs, and careful sequencing to avoid breaking production. Most teams manage this with spreadsheets, Slack threads, and a healthy dose of hope.

JuhJuh was built for this complexity. Here is how the multi-repo orchestration model works.

The multi-repo problem

Modern architectures fragment codebases intentionally. Microservices, monorepos with packages, frontend/backend splits, and shared libraries. These patterns exist because they solve real organizational problems. But they create coordination overhead that scales poorly.

Consider a typical feature: add a new field to a user profile. The work involves:

1. Database migration in the backend repo
2. API endpoint changes in the backend repo
3. Type updates in a shared types package
4. UI changes in the frontend repo
5. Integration test updates across repos

Without orchestration, this means five context switches, five terminal sessions, and no shared understanding of what each step accomplished.

Managed workspace architecture

JuhJuh maintains a PROJECTS/ directory as a managed workspace. When you connect a code repository to a project, JuhJuh clones it, tracks its state, and keeps it synchronized. Multiple repos coexist in the same workspace, and JuhJuh understands the relationships between them.

PROJECTS/
  api-backend/
  frontend-app/
  shared-types/
  infrastructure/

Each repository is cloned once and updated incrementally. JuhJuh tracks the current branch, uncommitted changes, and remote synchronization status. The dashboard shows repository health at a glance.

Worktree isolation for safe execution

Every AI execution runs in an isolated git worktree. When you execute a ticket against the api-backend repo, JuhJuh creates a worktree on a feature branch. The main branch is never modified directly.

This isolation model has three critical properties:

1. Parallel execution: Multiple tickets can execute against the same repo simultaneously, each in its own worktree
2. Safe failure: If an execution produces bad code, discard the worktree and start fresh
3. Clean separation: Work-in-progress code never contaminates the shared branch until explicitly merged

Worktrees are lightweight. They share the git object database with the main clone. Creating one takes milliseconds, not the minutes required for a full clone.

Service dependency mapping

JuhJuh tracks seven types of service dependencies:

• API consumer: Service A calls Service B's HTTP endpoints
• Database shared: Services read/write to the same database
• Message queue: Services communicate via async messaging
• Shared library: Services import the same package
• Authentication: Service A validates tokens from Service B
• File system: Services access the same storage
• Configuration: Services share environment or config sources

When you execute a ticket, JuhJuh's analysis phase identifies which repos might be affected based on these relationships. A change to an API endpoint surfaces the frontend services that consume it. A database schema change highlights every service that queries that table.

This dependency graph informs both the AI prompts (so Claude understands the broader context) and the human review process (so reviewers know what else might need attention).

Context flow between repositories

The real power of multi-repo orchestration emerges when tickets span multiple codebases. JuhJuh handles this through context propagation.

When you execute a ticket with a scope that crosses repos, each execution phase feeds context into the next:

1. First repo execution completes, producing file changes and architectural decisions
2. Those outputs become inputs to the second repo's prompts
3. The second execution understands what the first accomplished

For example, a ticket that adds a new API endpoint might execute in this sequence:

1. Backend repo: Create the endpoint, define request/response schemas
2. Shared types repo: Add TypeScript types matching the new schemas
3. Frontend repo: Add the API client call and UI components

Each phase knows what the previous phases produced. The frontend execution does not have to guess at the API shape. It has the actual schema from the backend execution.

Practical patterns for multi-repo work

Pattern 1: Sequential feature rollout

For features that require coordinated changes:

1. Create an Epic with child tickets for each repo
2. Order tickets by dependency (infrastructure first, frontend last)
3. Use Auto-Play for sequential execution with sibling context
4. Review the combined diff across all repos before any merges

Pattern 2: Shared library updates

When updating a shared library:

1. Create a ticket for the library changes
2. Create child tickets for each consuming service
3. Execute the library ticket first
4. Consumer tickets receive the updated library context automatically

Pattern 3: API versioning

For breaking API changes:

1. Create tickets for the new API version
2. Create parallel tickets for consumer migration
3. Execute API changes first
4. Consumer migrations inherit the new contract definition

What this means for engineering velocity

Multi-repo orchestration eliminates the coordination tax that slows down cross-cutting features. Instead of five engineers synchronizing through Slack, one engineer executes an Epic and reviews the combined output.

The numbers vary by team, but the pattern is consistent: features that previously required multi-day coordination cycles complete in single sessions. PR review becomes tractable because reviewers see the full context, not fragmented slices.

This is not about replacing engineers. It is about removing the overhead that prevents engineers from shipping. The architecture decisions, the code review, and the testing strategy remain human responsibilities. JuhJuh handles the mechanical orchestration that used to consume hours of context-switching.