Support mono-repos with multiple languages

[markcallen]

Summary

After multi-language support is implemented (#22), ballast should support mono-repos that contain projects in multiple languages (e.g., a TypeScript frontend, Python backend, and Go service in the same repository).

Motivation

Many teams use mono-repos with mixed stacks:

• TypeScript/Next.js frontend + Python/FastAPI backend
• Go services + Python ML pipelines
• TypeScript tooling + Go CLI utilities

Today, each ballast package (ballast, ballast-python, ballast-go) targets a single language. In a mono-repo, users would need to run multiple installers and manually coordinate which rules apply where.

Proposed behavior

1. Unified install for mono-repos

A single command (or coordinated workflow) that:

• Detects which languages are present in the repo (e.g., package.json, pyproject.toml, go.mod)
• Installs the appropriate agents for each detected language
• Writes rules to the correct locations, with path scoping so rules apply only where relevant

2. Path-scoped rules

Rules should be scoped to the directories they apply to:

Platform	Mechanism	Example
Cursor	.cursor/rules/*.mdc with globs in frontmatter	globs: ["packages/frontend/**"]
Claude	Per-directory .claude/rules/ or rule metadata	TBD per Claude's capabilities
OpenCode	Similar path scoping	TBD
Codex	Per-directory or glob-based	TBD

3. Example mono-repo layout

my-monorepo/
├── packages/
│   ├── frontend/          # TypeScript
│   │   ├── package.json
│   │   └── ...
│   ├── api/               # Python
│   │   ├── pyproject.toml
│   │   └── ...
│   └── worker/            # Go
│       ├── go.mod
│       └── ...
├── .cursor/rules/
│   ├── linting-ts.mdc     # globs: ["packages/frontend/**"]
│   ├── linting-py.mdc     # globs: ["packages/api/**"]
│   ├── linting-go.mdc     # globs: ["packages/worker/**"]
│   └── local-dev.mdc      # globs: ["**"] (root/common)
└── .rulesrc.json          # { "languages": ["typescript", "python", "go"], "paths": {...} }

4. Config and CLI

• .rulesrc.json (or equivalent) should support:
  • languages: array of detected or selected languages
  • paths: optional mapping of language → directory (e.g., {"python": "packages/api", "go": "packages/worker"})
• CLI: ballast install in a mono-repo could:
  • Auto-detect languages and prompt: "Found TypeScript, Python, Go. Install rules for all? [Y/n]"
  • Or accept --languages typescript,python,go and --paths for custom layouts

5. Implementation dependencies

• Requires #22 (multi-language support) to be done first
• May require a unified ballast CLI that can invoke language-specific installers, or a single CLI that understands all languages

Acceptance criteria

• Ballast can detect multiple languages in a single repository
• Rules are installed with path/glob scoping so they apply only to relevant directories
• Config (.rulesrc.json) supports multi-language and path mapping
• Works with common mono-repo layouts (e.g., packages/*, apps/*, root-level mix)
• Documentation covers mono-repo setup and configuration

Out of scope

• Full implementation details depend on #22 outcome
• Platform-specific path-scoping may vary (Cursor globs vs Claude/OpenCode/Codex capabilities)

[markcallen]

Adding requirement for release automation:

When any single language package is published via GitHub Actions (publish.typescript.yml, publish-python.yml, or publish-go.yml), the workflow should also support installing and validating Ballast rule generation across all three language profiles (TypeScript, Python, and Go) in the release process.

Proposed outcome:

• Keep per-language publish jobs runnable independently.
• Add a shared install/validation step (or reusable workflow) that runs cross-language install checks before/with publish so all language packs stay in sync operationally.