[Feature]: support and guidance for multi-repo products (microservices architecture)

Không có tệp hoặc bài kiểm thử nào được nêu tên. Hãy bắt đầu bằng việc xem lại hướng dẫn hiện có về monorepo và các quy trình khởi tạo cũng như lệnh của CLI, sau đó xác định mô hình nhiều repository ở cấp sản phẩm có thể phù hợp ở đâu. Được xem là hoàn tất khi việc liên kết giữa các repository, xử lý dependency, quản lý phiên bản, điều phối release và một ví dụ microservices hoàn chỉnh được ghi lại hoặc triển khai.

Problem Statement

Spec Kit currently provides guidance for monorepo scenarios, but many real-world products are built as multiple repositories (microservices), where each repository serves a different function within the same product.

For many organizations, monorepo is not viable due to constraints such as:

• security boundaries,
• team ownership models,
• compliance requirements,
• independent release cadences,
• operational limitations.

Without a dedicated multi-repo approach, applying Spec-Driven Development consistently at the product level becomes difficult, especially for cross-service changes.

Proposed Solution

Add official support (feature and/or documentation) for a multi-repo product workflow tailored to microservices architectures.

Suggested scope:

• Define a way to represent a product as a logical grouping of multiple repositories/services.
• Support linking and tracking spec dependencies across repos.
• Provide a recommended workflow for cross-repo changes, including:
• creating/updating specs per service,
• dependency management,
• compatibility validation,
• release coordination.
• Establish conventions for versioning and traceability across repositories.
• Include practical, end-to-end examples for non-monorepo microservices.

Alternatives Considered

Use monorepo guidance as-is
Not sufficient when monorepo cannot be adopted for organizational or technical reasons.

Keep ad-hoc team conventions per repo
Leads to inconsistent practices, weak traceability, and higher coordination overhead.

Rely only on external tooling/process docs
Helps partially, but lacks first-class, opinionated support within Spec Kit’s own workflow.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

GitHub Copilot

Use Cases

1. A product is composed of several microservices, each in its own repository.
2. A product-level feature requires coordinated updates to multiple services/specs.
3. An API contract change in one service affects dependent services in other repos.
4. Teams need clear mapping from product intent/spec to implementation across all involved repositories.
5. Release readiness depends on compatibility and sequencing across multiple repos.

Acceptance Criteria

• Documentation clearly describes when and how to use a multi-repo workflow (especially when monorepo is not possible).
• A product-level model/grouping for multiple repos/services is defined.
• Cross-repo spec linking/dependency handling is documented (or supported as a feature).
• A recommended end-to-end flow for cross-repo changes is provided.
• Versioning and traceability conventions across repos are defined.
• At least one practical microservices example (non-monorepo) is included.

Additional Context

No response