Enhancement: Monorepo-aware features for multi-service architectures

[frankbria]

Background

Split from #64. The core existing-project support and .ralphrc configuration are now complete. This issue captures the monorepo-specific features that were proposed but not yet implemented.

Proposed Features

1. MONOREPO_SERVICES configuration in .ralphrc

Add support for declaring service boundaries in .ralphrc:

# Example .ralphrc additions
MONOREPO_SERVICES="api,web,shared,workers"
MONOREPO_ROOT="services/"

Use case: Projects with multiple services (e.g., services/api/, services/web/, packages/shared/) where Ralph needs awareness of the structure.

2. Monorepo-aware PROMPT.md template

Add guidance in the generated PROMPT.md for:

• Service boundary detection: Help Ralph understand which service it's modifying
• Cross-service change handling: When changes in one service require updates to another (e.g., shared types, API contracts)
• Scoped testing: Run tests only for affected services

Example additions to PROMPT.md:

## Monorepo Guidelines
- This project contains multiple services: {{SERVICES}}
- When modifying shared code, check for impacts in dependent services
- Run service-specific tests: `npm test --workspace={{service}}`

3. Service-scoped Ralph execution (optional)

Allow running Ralph on a specific service:

ralph --service api

This would:

• Set working context to that service
• Adjust PROMPT.md scope dynamically
• Run only relevant tests

---

Questions to evaluate

Before implementing, consider:

1. Is this needed? Do users actually run Ralph at repo root for monorepos, or do they cd into each service?
2. Complexity vs. value: Would simple documentation suffice, or does Ralph need code changes?
3. Alternative: Could this be solved with multiple .ralph/ directories (one per service)?

Related

• Closes the monorepo portion of Feature Proposal: Monorepo Support & .ralphrc Configuration File #64
• Original proposal by external contributor exploring Ralph for existing monorepo projects

[traycerai]

Plan

Observations

Ralph currently has robust project detection for single-service projects (JavaScript/TypeScript, Python, Rust, Go) with framework-aware configuration generation. The lib/enable_core.sh module handles project context detection via detect_project_context(), which identifies project type, build commands, and frameworks from manifest files like package.json, pyproject.toml, etc. However, there's no existing monorepo detection or workspace-aware functionality. The architecture is well-structured with separation of concerns: templates for configuration, library modules for detection logic, and wizard utilities for interactive setup.

Approach

The implementation will add optional monorepo awareness without disrupting single-service workflows. The strategy involves: (1) extending project detection to identify monorepo structures (npm/yarn/pnpm workspaces, Lerna, Turborepo, Nx), (2) adding configuration options to .ralphrc for declaring service boundaries, (3) enhancing PROMPT.md template generation with monorepo-specific guidance when detected, and (4) optionally supporting service-scoped execution via --service flag. This approach maintains backward compatibility while providing value for multi-service architectures through intelligent defaults and opt-in features.

Implementation Steps

1. Extend Monorepo Detection in file:lib/enable_core.sh

Add a new function detect_monorepo_structure() after the existing detect_task_sources() function (around line 456):

Detection logic should identify:

• npm/yarn/pnpm workspaces: Check for workspaces field in package.json or pnpm-workspace.yaml
• Lerna: Check for lerna.json
• Turborepo: Check for turbo.json
• Nx: Check for nx.json
• Python monorepos: Check for multiple pyproject.toml files in subdirectories
• Rust workspaces: Check for [workspace] section in root Cargo.toml
• Go multi-module: Check for multiple go.mod files

Export global variables:

export DETECTED_MONOREPO="false"
export DETECTED_MONOREPO_TYPE=""  # workspace, lerna, turborepo, nx, rust-workspace, etc.
export DETECTED_SERVICES=()       # Array of service/package names
export DETECTED_MONOREPO_ROOT=""  # Root directory for services (e.g., "packages/", "apps/")

Implementation details:

• Parse package.json workspaces array using jq if available, fallback to grep
• For pnpm, parse pnpm-workspace.yaml
• Scan filesystem for service directories matching workspace patterns
• Limit service detection to reasonable depth (2-3 levels) to avoid performance issues
• Store service names in DETECTED_SERVICES array for later use

2. Update .ralphrc Template in file:templates/ralphrc.template

Add new monorepo configuration section after line 96 (before the end of file):

# =============================================================================
# MONOREPO CONFIGURATION (Optional)
# =============================================================================

# Enable monorepo mode (auto-detected, can override)
# MONOREPO_ENABLED=false

# Comma-separated list of services/packages
# Example: "api,web,shared,workers"
# MONOREPO_SERVICES=""

# Root directory containing services
# Example: "packages/", "apps/", "services/"
# MONOREPO_ROOT=""

# Service-specific context (when using --service flag)
# MONOREPO_CURRENT_SERVICE=""

Update generate_ralphrc() function in file:lib/enable_core.sh (around line 668):

• Accept additional parameters for monorepo settings
• Conditionally include monorepo configuration if DETECTED_MONOREPO="true"
• Populate MONOREPO_SERVICES with detected services (comma-separated)
• Set MONOREPO_ROOT based on detected workspace root pattern

3. Enhance PROMPT.md Template Generation

Modify generate_prompt_md() function in file:lib/enable_core.sh (around line 495):

Add a new parameter $5 (monorepo_context) containing monorepo-specific guidance.

When monorepo is detected, inject section after "## Context" (around line 524):

## Monorepo Structure

This project is a monorepo containing multiple services: {{SERVICES_LIST}}

**Service Boundaries**:
- Services are located in: {{MONOREPO_ROOT}}
- Each service has its own dependencies and build configuration
- Shared code should be placed in common/shared packages

**Cross-Service Changes**:
- When modifying shared packages, verify impact on dependent services
- Run tests for all affected services, not just the one being modified
- Update API contracts carefully to avoid breaking changes
- Document cross-service dependencies in specs/

**Testing Strategy**:
- Run service-specific tests: {{SERVICE_TEST_COMMAND}}
- For shared changes, run full monorepo test suite
- Use workspace commands to target specific services

Template variables to replace:

• {{SERVICES_LIST}}: Comma-separated list from DETECTED_SERVICES
• {{MONOREPO_ROOT}}: Value from DETECTED_MONOREPO_ROOT
• {{SERVICE_TEST_COMMAND}}: Workspace-aware test command (e.g., npm test --workspace=api)

4. Add Monorepo Detection to Enable Workflow

Update enable_ralph_in_directory() function in file:lib/enable_core.sh (around line 726):

After calling detect_project_context() (line 743), add:

# Detect monorepo structure
detect_monorepo_structure

Update phase_environment_detection() in file:ralph_enable.sh (around line 178):

After project type detection (line 222), add monorepo detection results:

# Display monorepo detection
if [[ "$DETECTED_MONOREPO" == "true" ]]; then
    print_detection_result "Monorepo type" "$DETECTED_MONOREPO_TYPE" "true"
    print_detection_result "Services found" "${#DETECTED_SERVICES[@]}" "true"
    if [[ -n "$DETECTED_MONOREPO_ROOT" ]]; then
        print_detection_result "Services root" "$DETECTED_MONOREPO_ROOT" "true"
    fi
fi

5. Service-Scoped Execution (Optional Enhancement)

Add --service flag support to file:ralph_loop.sh:

This is the most complex feature and should be implemented last, as it requires:

Argument parsing:

• Add --service <name> option to command-line parser
• Validate service name against MONOREPO_SERVICES from .ralphrc
• Set working directory context to service subdirectory

Dynamic PROMPT.md scoping:

• When --service is specified, inject service-specific context into PROMPT.md
• Override MONOREPO_CURRENT_SERVICE in environment
• Adjust file paths and test commands to be service-relative

Implementation approach:

# In ralph_loop.sh argument parsing
SERVICE_SCOPE=""
while [[ $# -gt 0 ]]; do
    case "$1" in
        --service)
            SERVICE_SCOPE="$2"
            shift 2
            ;;
        # ... other options
    esac
done

# Validate service scope
if [[ -n "$SERVICE_SCOPE" ]]; then
    source .ralphrc
    if [[ ! "$MONOREPO_SERVICES" =~ (^|,)$SERVICE_SCOPE(,|$) ]]; then
        echo "Error: Service '$SERVICE_SCOPE' not found in MONOREPO_SERVICES"
        exit 1
    fi
    # Set service context
    export MONOREPO_CURRENT_SERVICE="$SERVICE_SCOPE"
    # Optionally cd into service directory
    if [[ -n "$MONOREPO_ROOT" && -d "$MONOREPO_ROOT$SERVICE_SCOPE" ]]; then
        cd "$MONOREPO_ROOT$SERVICE_SCOPE" || exit 1
    fi
fi

6. Documentation Updates

Create new documentation file file:docs/user-guide/05-monorepo-support.md:

Include sections on:

• What monorepo support provides
• Automatic detection vs. manual configuration
• When to use --service flag vs. running at repo root
• Best practices for cross-service changes
• Examples for different monorepo tools (npm workspaces, Lerna, Turborepo, Nx)
• Alternative approach: multiple .ralph/ directories per service

Update file:README.md:

• Add monorepo support to features list
• Include quick example of enabling Ralph in a monorepo
• Link to detailed monorepo documentation

Update file:docs/user-guide/02-understanding-ralph-files.md:

• Add section explaining .ralphrc monorepo configuration options
• Document how PROMPT.md changes in monorepo context

7. Testing Strategy

Add unit tests in file:tests/unit/test_enable_core.bats:

Test cases for detect_monorepo_structure():

• Detect npm workspaces from package.json
• Detect pnpm workspaces from pnpm-workspace.yaml
• Detect Lerna from lerna.json
• Detect Turborepo from turbo.json
• Detect Nx from nx.json
• Detect Rust workspace from Cargo.toml
• Handle non-monorepo projects (should not false-positive)
• Handle edge cases (empty workspaces, malformed configs)

Add integration tests in file:tests/integration/test_monorepo_enable.bats:

Test scenarios:

• Enable Ralph in npm workspace monorepo
• Enable Ralph in Lerna monorepo
• Verify .ralphrc contains correct MONOREPO_SERVICES
• Verify PROMPT.md includes monorepo guidance
• Test --service flag with valid service name
• Test --service flag with invalid service name (should error)

Create test fixtures:

• file:tests/fixtures/monorepo-npm/ - Sample npm workspace
• file:tests/fixtures/monorepo-lerna/ - Sample Lerna project
• file:tests/fixtures/monorepo-turborepo/ - Sample Turborepo project

8. Evaluation and Decision Points

Before full implementation, validate these assumptions:

1. User behavior analysis: Do Ralph users actually run from monorepo root, or do they cd into services?

   • Survey existing users or check usage patterns
   • If most users work service-by-service, simpler documentation may suffice

2. Complexity vs. value trade-off:

   • Monorepo detection adds ~200 lines of code
   • Service-scoped execution adds ~100 lines
   • Is this worth the maintenance burden?

3. Alternative: Multiple .ralph/ directories:

   • Each service could have its own .ralph/ configuration
   • Simpler implementation, more explicit
   • Trade-off: Duplication vs. centralized configuration

Recommendation: Implement phases 1-4 (detection and configuration) first, gather user feedback, then decide on phase 5 (service-scoped execution) based on actual usage patterns.

Architecture Diagram

sequenceDiagram
    participant User
    participant ralph_enable.sh
    participant enable_core.sh
    participant Filesystem
    participant Templates

    User->>ralph_enable.sh: ralph enable
    ralph_enable.sh->>enable_core.sh: detect_project_context()
    enable_core.sh->>Filesystem: Check package.json, Cargo.toml, etc.
    Filesystem-->>enable_core.sh: Project metadata
    
    ralph_enable.sh->>enable_core.sh: detect_monorepo_structure()
    enable_core.sh->>Filesystem: Check workspaces, lerna.json, turbo.json
    Filesystem-->>enable_core.sh: Monorepo structure
    enable_core.sh-->>ralph_enable.sh: DETECTED_MONOREPO=true, DETECTED_SERVICES=[...]
    
    ralph_enable.sh->>enable_core.sh: generate_ralphrc()
    enable_core.sh->>Templates: Load ralphrc.template
    enable_core.sh->>enable_core.sh: Inject MONOREPO_SERVICES, MONOREPO_ROOT
    enable_core.sh-->>ralph_enable.sh: .ralphrc content
    
    ralph_enable.sh->>enable_core.sh: generate_prompt_md()
    enable_core.sh->>Templates: Load PROMPT.md template
    enable_core.sh->>enable_core.sh: Inject monorepo guidance section
    enable_core.sh-->>ralph_enable.sh: PROMPT.md content
    
    ralph_enable.sh->>Filesystem: Write .ralph/PROMPT.md, .ralphrc
    ralph_enable.sh-->>User: Ralph enabled with monorepo support

Loading

Configuration Example

After running ralph enable in a monorepo, the generated .ralphrc would contain:

# Project identification
PROJECT_NAME="my-monorepo"
PROJECT_TYPE="typescript"

# Monorepo configuration
MONOREPO_ENABLED=true
MONOREPO_SERVICES="api,web,shared,workers"
MONOREPO_ROOT="packages/"

And the generated PROMPT.md would include:

## Monorepo Structure

This project is a monorepo containing multiple services: api, web, shared, workers

**Service Boundaries**:
- Services are located in: packages/
- Each service has its own dependencies and build configuration
- Shared code should be placed in common/shared packages

**Cross-Service Changes**:
- When modifying shared packages, verify impact on dependent services
- Run tests for all affected services
- Document cross-service dependencies in specs/

Import In IDE

🤖 Prompt for AI Agents

## Observations

Ralph currently has robust project detection for single-service projects (JavaScript/TypeScript, Python, Rust, Go) with framework-aware configuration generation. The `lib/enable_core.sh` module handles project context detection via `detect_project_context()`, which identifies project type, build commands, and frameworks from manifest files like `package.json`, `pyproject.toml`, etc. However, there's no existing monorepo detection or workspace-aware functionality. The architecture is well-structured with separation of concerns: templates for configuration, library modules for detection logic, and wizard utilities for interactive setup.

## Approach

The implementation will add **optional** monorepo awareness without disrupting single-service workflows. The strategy involves: (1) extending project detection to identify monorepo structures (npm/yarn/pnpm workspaces, Lerna, Turborepo, Nx), (2) adding configuration options to `.ralphrc` for declaring service boundaries, (3) enhancing `PROMPT.md` template generation with monorepo-specific guidance when detected, and (4) optionally supporting service-scoped execution via `--service` flag. This approach maintains backward compatibility while providing value for multi-service architectures through intelligent defaults and opt-in features.

## Implementation Steps

### 1. Extend Monorepo Detection in `file:lib/enable_core.sh`

Add a new function `detect_monorepo_structure()` after the existing `detect_task_sources()` function (around line 456):

**Detection logic should identify**:
- **npm/yarn/pnpm workspaces**: Check for `workspaces` field in `package.json` or `pnpm-workspace.yaml`
- **Lerna**: Check for `lerna.json`
- **Turborepo**: Check for `turbo.json`
- **Nx**: Check for `nx.json`
- **Python monorepos**: Check for multiple `pyproject.toml` files in subdirectories
- **Rust workspaces**: Check for `[workspace]` section in root `Cargo.toml`
- **Go multi-module**: Check for multiple `go.mod` files

**Export global variables**:
```bash
export DETECTED_MONOREPO="false"
export DETECTED_MONOREPO_TYPE=""  # workspace, lerna, turborepo, nx, rust-workspace, etc.
export DETECTED_SERVICES=()       # Array of service/package names
export DETECTED_MONOREPO_ROOT=""  # Root directory for services (e.g., "packages/", "apps/")
```

**Implementation details**:
- Parse `package.json` workspaces array using `jq` if available, fallback to `grep`
- For pnpm, parse `pnpm-workspace.yaml` 
- Scan filesystem for service directories matching workspace patterns
- Limit service detection to reasonable depth (2-3 levels) to avoid performance issues
- Store service names in `DETECTED_SERVICES` array for later use

### 2. Update `.ralphrc` Template in `file:templates/ralphrc.template`

Add new monorepo configuration section after line 96 (before the end of file):

```bash
# =============================================================================
# MONOREPO CONFIGURATION (Optional)
# =============================================================================

# Enable monorepo mode (auto-detected, can override)
# MONOREPO_ENABLED=false

# Comma-separated list of services/packages
# Example: "api,web,shared,workers"
# MONOREPO_SERVICES=""

# Root directory containing services
# Example: "packages/", "apps/", "services/"
# MONOREPO_ROOT=""

# Service-specific context (when using --service flag)
# MONOREPO_CURRENT_SERVICE=""
```

**Update `generate_ralphrc()` function** in `file:lib/enable_core.sh` (around line 668):
- Accept additional parameters for monorepo settings
- Conditionally include monorepo configuration if `DETECTED_MONOREPO="true"`
- Populate `MONOREPO_SERVICES` with detected services (comma-separated)
- Set `MONOREPO_ROOT` based on detected workspace root pattern

### 3. Enhance PROMPT.md Template Generation

**Modify `generate_prompt_md()` function** in `file:lib/enable_core.sh` (around line 495):

Add a new parameter `$5 (monorepo_context)` containing monorepo-specific guidance.

**When monorepo is detected, inject section after "## Context"** (around line 524):

```markdown
## Monorepo Structure

This project is a monorepo containing multiple services: {{SERVICES_LIST}}

**Service Boundaries**:
- Services are located in: {{MONOREPO_ROOT}}
- Each service has its own dependencies and build configuration
- Shared code should be placed in common/shared packages

**Cross-Service Changes**:
- When modifying shared packages, verify impact on dependent services
- Run tests for all affected services, not just the one being modified
- Update API contracts carefully to avoid breaking changes
- Document cross-service dependencies in specs/

**Testing Strategy**:
- Run service-specific tests: {{SERVICE_TEST_COMMAND}}
- For shared changes, run full monorepo test suite
- Use workspace commands to target specific services
```

**Template variables to replace**:
- `{{SERVICES_LIST}}`: Comma-separated list from `DETECTED_SERVICES`
- `{{MONOREPO_ROOT}}`: Value from `DETECTED_MONOREPO_ROOT`
- `{{SERVICE_TEST_COMMAND}}`: Workspace-aware test command (e.g., `npm test --workspace=api`)

### 4. Add Monorepo Detection to Enable Workflow

**Update `enable_ralph_in_directory()` function** in `file:lib/enable_core.sh` (around line 726):

After calling `detect_project_context()` (line 743), add:
```bash
# Detect monorepo structure
detect_monorepo_structure
```

**Update `phase_environment_detection()` in `file:ralph_enable.sh`** (around line 178):

After project type detection (line 222), add monorepo detection results:
```bash
# Display monorepo detection
if [[ "$DETECTED_MONOREPO" == "true" ]]; then
    print_detection_result "Monorepo type" "$DETECTED_MONOREPO_TYPE" "true"
    print_detection_result "Services found" "${#DETECTED_SERVICES[@]}" "true"
    if [[ -n "$DETECTED_MONOREPO_ROOT" ]]; then
        print_detection_result "Services root" "$DETECTED_MONOREPO_ROOT" "true"
    fi
fi
```

### 5. Service-Scoped Execution (Optional Enhancement)

**Add `--service` flag support to `file:ralph_loop.sh`**:

This is the most complex feature and should be implemented last, as it requires:

**Argument parsing**:
- Add `--service <name>` option to command-line parser
- Validate service name against `MONOREPO_SERVICES` from `.ralphrc`
- Set working directory context to service subdirectory

**Dynamic PROMPT.md scoping**:
- When `--service` is specified, inject service-specific context into PROMPT.md
- Override `MONOREPO_CURRENT_SERVICE` in environment
- Adjust file paths and test commands to be service-relative

**Implementation approach**:
```bash
# In ralph_loop.sh argument parsing
SERVICE_SCOPE=""
while [[ $# -gt 0 ]]; do
    case "$1" in
        --service)
            SERVICE_SCOPE="$2"
            shift 2
            ;;
        # ... other options
    esac
done

# Validate service scope
if [[ -n "$SERVICE_SCOPE" ]]; then
    source .ralphrc
    if [[ ! "$MONOREPO_SERVICES" =~ (^|,)$SERVICE_SCOPE(,|$) ]]; then
        echo "Error: Service '$SERVICE_SCOPE' not found in MONOREPO_SERVICES"
        exit 1
    fi
    # Set service context
    export MONOREPO_CURRENT_SERVICE="$SERVICE_SCOPE"
    # Optionally cd into service directory
    if [[ -n "$MONOREPO_ROOT" && -d "$MONOREPO_ROOT$SERVICE_SCOPE" ]]; then
        cd "$MONOREPO_ROOT$SERVICE_SCOPE" || exit 1
    fi
fi
```

### 6. Documentation Updates

**Create new documentation file** `file:docs/user-guide/05-monorepo-support.md`:

Include sections on:
- What monorepo support provides
- Automatic detection vs. manual configuration
- When to use `--service` flag vs. running at repo root
- Best practices for cross-service changes
- Examples for different monorepo tools (npm workspaces, Lerna, Turborepo, Nx)
- Alternative approach: multiple `.ralph/` directories per service

**Update `file:README.md`**:
- Add monorepo support to features list
- Include quick example of enabling Ralph in a monorepo
- Link to detailed monorepo documentation

**Update `file:docs/user-guide/02-understanding-ralph-files.md`**:
- Add section explaining `.ralphrc` monorepo configuration options
- Document how PROMPT.md changes in monorepo context

### 7. Testing Strategy

**Add unit tests** in `file:tests/unit/test_enable_core.bats`:

Test cases for `detect_monorepo_structure()`:
- Detect npm workspaces from `package.json`
- Detect pnpm workspaces from `pnpm-workspace.yaml`
- Detect Lerna from `lerna.json`
- Detect Turborepo from `turbo.json`
- Detect Nx from `nx.json`
- Detect Rust workspace from `Cargo.toml`
- Handle non-monorepo projects (should not false-positive)
- Handle edge cases (empty workspaces, malformed configs)

**Add integration tests** in `file:tests/integration/test_monorepo_enable.bats`:

Test scenarios:
- Enable Ralph in npm workspace monorepo
- Enable Ralph in Lerna monorepo
- Verify `.ralphrc` contains correct MONOREPO_SERVICES
- Verify PROMPT.md includes monorepo guidance
- Test `--service` flag with valid service name
- Test `--service` flag with invalid service name (should error)

**Create test fixtures**:
- `file:tests/fixtures/monorepo-npm/` - Sample npm workspace
- `file:tests/fixtures/monorepo-lerna/` - Sample Lerna project
- `file:tests/fixtures/monorepo-turborepo/` - Sample Turborepo project

### 8. Evaluation and Decision Points

**Before full implementation, validate these assumptions**:

1. **User behavior analysis**: Do Ralph users actually run from monorepo root, or do they `cd` into services?
   - Survey existing users or check usage patterns
   - If most users work service-by-service, simpler documentation may suffice

2. **Complexity vs. value trade-off**:
   - Monorepo detection adds ~200 lines of code
   - Service-scoped execution adds ~100 lines
   - Is this worth the maintenance burden?

3. **Alternative: Multiple `.ralph/` directories**:
   - Each service could have its own `.ralph/` configuration
   - Simpler implementation, more explicit
   - Trade-off: Duplication vs. centralized configuration

**Recommendation**: Implement phases 1-4 (detection and configuration) first, gather user feedback, then decide on phase 5 (service-scoped execution) based on actual usage patterns.

## Architecture Diagram

```mermaid
sequenceDiagram
    participant User
    participant ralph_enable.sh
    participant enable_core.sh
    participant Filesystem
    participant Templates

    User->>ralph_enable.sh: ralph enable
    ralph_enable.sh->>enable_core.sh: detect_project_context()
    enable_core.sh->>Filesystem: Check package.json, Cargo.toml, etc.
    Filesystem-->>enable_core.sh: Project metadata
    
    ralph_enable.sh->>enable_core.sh: detect_monorepo_structure()
    enable_core.sh->>Filesystem: Check workspaces, lerna.json, turbo.json
    Filesystem-->>enable_core.sh: Monorepo structure
    enable_core.sh-->>ralph_enable.sh: DETECTED_MONOREPO=true, DETECTED_SERVICES=[...]
    
    ralph_enable.sh->>enable_core.sh: generate_ralphrc()
    enable_core.sh->>Templates: Load ralphrc.template
    enable_core.sh->>enable_core.sh: Inject MONOREPO_SERVICES, MONOREPO_ROOT
    enable_core.sh-->>ralph_enable.sh: .ralphrc content
    
    ralph_enable.sh->>enable_core.sh: generate_prompt_md()
    enable_core.sh->>Templates: Load PROMPT.md template
    enable_core.sh->>enable_core.sh: Inject monorepo guidance section
    enable_core.sh-->>ralph_enable.sh: PROMPT.md content
    
    ralph_enable.sh->>Filesystem: Write .ralph/PROMPT.md, .ralphrc
    ralph_enable.sh-->>User: Ralph enabled with monorepo support
```

## Configuration Example

After running `ralph enable` in a monorepo, the generated `.ralphrc` would contain:

```bash
# Project identification
PROJECT_NAME="my-monorepo"
PROJECT_TYPE="typescript"

# Monorepo configuration
MONOREPO_ENABLED=true
MONOREPO_SERVICES="api,web,shared,workers"
MONOREPO_ROOT="packages/"
```

And the generated `PROMPT.md` would include:

```markdown
## Monorepo Structure

This project is a monorepo containing multiple services: api, web, shared, workers

**Service Boundaries**:
- Services are located in: packages/
- Each service has its own dependencies and build configuration
- Shared code should be placed in common/shared packages

**Cross-Service Changes**:
- When modifying shared packages, verify impact on dependent services
- Run tests for all affected services
- Document cross-service dependencies in specs/
```

---

Execution Information

Branch: main
Commit: abcfa8b

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[Koroqe]

The "implementation slice" pattern helps here — each slice targets a specific service with boundaries defined in the architecture doc. The architect explicitly maps affected services and interactions, then the implementer works within those boundaries. https://github.com/Koroqe/claude-code-sdlc does this — the architecture phase defines component boundaries before any implementation starts.