Multi-repo project #106
Replies: 7 comments
-
|
I have the same setup. with RepoX.Server RepoX.Client RepoX.Tools etc (all separate repositories, that i want to be able to manage all of them at once. |
Beta Was this translation helpful? Give feedback.
-
|
We have started the RFC for this, but its a very big change. Let us know how you use submodules and/or multi-repo and would like it to work in AC, we will also prioritize it based on upvotes on this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Based on 2.7.4 I've been running some tests and it seems to be working fine It was quite hard to get working, the app probably needs some architecture reworks that I definitely did not do because it was complicated to implement. No guarantees, but I'm using it right now https://github.com/aqua-pro/Auto-Claude/commits/feature/submodule-support/ |
Beta Was this translation helpful? Give feedback.
-
|
Proposal: Root-Level Project Context for Product-Oriented Kanban Tasks I really like the concept of this product: using a Kanban board as the source of truth while an AI agent visually progresses tasks through stages (including human review). It feels like a very natural way to observe and guide how the AI writes code, and from a UX and workflow perspective, it is genuinely impressive. I would like to propose an enhancement / alternative usage pattern that could significantly improve product-level workflows. Current limitation (from a product perspective) Today, to achieve this, I need to: This pushes me to think in a service-oriented way instead of a product-oriented way. It also fragments context: Proposed idea: Root-level project context Example structure: /product-root
Each subdirectory may be its own Git repository or logical service, but they all belong to the same product. The key idea is: Desired behavior “Implement user authentication API” The AI agent should: All of this would be driven by one task, moving through the Kanban stages, with human review where appropriate. Why this matters In practice, an AI that knows how it implemented the backend can implement a better frontend. An AI that understands both can write better tests. And with that context, infrastructure changes also become more accurate. Summary By allowing a root-level directory as the project context, a single Kanban task could orchestrate work across multiple services in a way that feels far more natural for real product development. I believe this would unlock a much more powerful and realistic workflow for complex systems. |
Beta Was this translation helpful? Give feedback.
-
|
Current RFC done with Claude Code: RFC: Git Submodule & Multi-Repo Support for AutoClaudeStatus: Proposal Executive SummaryThis RFC proposes adding support for git submodules and multi-repository project structures to AutoClaude. The current architecture is fundamentally a single-repo system with deep assumptions about one project = one git repository throughout the codebase. Estimated Scope: 10-12 weeks across 3 phases Problem StatementUser Feedback
Core LimitationWhen a user creates a task on the Kanban board for full automatic feature creation, the AI only has access to ONE repository. For projects with frontend/backend separation across repos, this means:
Current Architecture Analysis1. Project = Single Git RepositoryHow it works today:
Key data structures: // apps/frontend/src/main/project-store.ts
Project {
id: string
name: string
path: string // <-- Single filesystem path
autoBuildPath: string // '.auto-claude'
settings: ProjectSettings
}
// GitHub association (via .env files)
ProjectEnvConfig {
githubEnabled: boolean
githubRepo?: string // Format: owner/repo - SINGLE REPO
}2. Worktree Isolation is Per-RepoCurrent design (
What breaks with submodules:
3. Context Discovery Assumes Single RootProject analyzer (
4. Security Model Restricts to Single DirectorySecurity hooks (
User Scenarios to SupportScenario A: Git SubmodulesUser expectation: "When I create a task, the AI should be able to modify code in both frontend/ and backend/ submodules" Scenario B: Multi-Repo (Sibling Repos)User expectation: "I want ONE AutoClaude project that can create tasks spanning both repos, and the AI should understand both codebases"Proposed SolutionRequirements (from stakeholder input)
Phased ImplementationPhase 1: Foundation - Submodule Support (2-3 weeks)Quick win that addresses a common pattern while laying groundwork. Deliverables:
Files to modify:
Phase 2: Data Model - Project Groups (3-4 weeks)Introduce the multi-repo concept without full UI. New data structures: // apps/frontend/src/shared/types/project.ts
interface ProjectGroup {
id: string
name: string
description?: string
repositories: LinkedRepository[]
primaryRepositoryId?: string // Default for new tasks
createdAt: Date
updatedAt: Date
}
interface LinkedRepository {
id: string
name: string // Display name (e.g., "Frontend", "Backend")
path: string // Filesystem path
gitRemote?: string // e.g., "github.com/org/frontend"
role: 'primary' | 'secondary' // Primary gets .auto-claude/
}
// Spec metadata extension
interface SpecMetadata {
// ...existing fields...
targetRepositories: string[] // Repository IDs this spec affects
detectedRepositories?: string[] // AI-detected relevant repos
}Files to modify:
Phase 3: Full UI & Smart Detection (4-5 weeks)Complete user experience with intelligent repo detection. Deliverables:
Frontend components:
Backend components:
Technical DesignWorktree Strategy for Multi-RepoChallenge: Git worktrees can only branch from a single repository. Solution: Linked Worktrees For each spec in a multi-repo project group:
Context Merging for AgentsCurrent: Single New: Merged context from multiple repos # apps/backend/context/multi_repo_context.py (NEW)
class MultiRepoContextBuilder:
"""Builds unified context from multiple repositories."""
def build_context(
self,
project_group: ProjectGroup,
target_repos: list[str]
) -> MergedContext:
"""
1. Load project_index.json from each target repo
2. Merge into unified structure with repo prefixes
3. Handle naming conflicts (e.g., both have src/)
"""Merged context structure: {
"repositories": [
{
"id": "frontend",
"name": "Frontend",
"path": "/path/to/frontend",
"services": [...]
},
{
"id": "backend",
"name": "Backend",
"path": "/path/to/backend",
"services": [...]
}
],
"cross_repo_dependencies": [
{
"from": "frontend",
"to": "backend",
"type": "api_calls"
}
]
}Security Model ExtensionCurrent: Single New: Multiple allowed paths # apps/backend/core/security.py
class MultiRepoSecurityContext:
"""Security context for multi-repo operations."""
allowed_paths: list[Path] # All repos in the group
primary_path: Path # Primary repo (for writes)
read_only_paths: list[Path] # Secondary repos (read-only by default)Smart Detection Algorithmasync def detect_relevant_repos(
task_description: str,
repos: list[LinkedRepository]
) -> list[str]:
"""
Example input: "Add authentication to the frontend with backend API support"
1. Extract keywords: ["authentication", "frontend", "backend", "API"]
2. Match against repo names and contents
3. Use Claude for semantic understanding:
- "frontend" -> likely frontend repo
- "backend API" -> likely backend repo
- "authentication" -> could be both
4. Return: ["frontend", "backend"]
"""
# Build context about each repo
repo_summaries = [
f"{r.name}: {get_repo_summary(r)}"
for r in repos
]
# Ask Claude to determine relevance
prompt = f"""
Task: {task_description}
Available repositories:
{repo_summaries}
Which repositories are relevant to this task?
"""
response = await claude.complete(prompt)
return parse_repo_list(response)Files to Modify/CreatePhase 1: Submodule Support
Phase 2: Data Model
Phase 3: Full UI & Smart Detection
Risk Assessment
Verification Plan
Alternatives ConsideredOption A: Documentation Only (Rejected)Simply document how to use submodules manually and recommend monorepo structure. Why rejected: Doesn't solve the core user need for multi-repo project management. Option B: Submodule Support Only (Partial)Implement only git submodule support without the Project Groups concept. Why rejected: Doesn't address users with truly separate repositories (sibling repos). Option C: Full Multi-Repo from Start (Rejected)Implement everything at once without phasing. Why rejected: Too high risk for such an architectural change. Phased approach allows for learning and adjustment. Open Questions
References
|
Beta Was this translation helpful? Give feedback.
-
|
Only think I'm worried is that symlinked worktrees sound very error prone, suggestions? |
Beta Was this translation helpful? Give feedback.
-
|
I would like to propose an additional perspective: implementing a dedicated project or spec Repository to serve as a central hub for all specifications, architectural guidelines, and requirements. In my opinion, decoupling the “logic” from the ‘implementation’ could significantly streamline the management of multiple code repositories. For projects with only one repository, I don’t think it would be a disadvantage to have a "spec" repository for the project. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
My app isn't a mono repo actually, so I wondering how I can set up the project that manages several different repos at once (FE, BE, devops, common libs).
Any ideas or suggestions would be appreciated!
Beta Was this translation helpful? Give feedback.
All reactions