Teams working with microservice architectures need a way to manage specs that span multiple repositories (frontend, backend, etc.). This requires defining where specs should live and ensuring agents are aware of relevant code repositories for each change spec.
## Problem Teams working with microservice architectures maintain separate repositories for frontend, backend, and other services. A single feature or change often spans multiple repos, creating several challenges: 1. **Where should specs live?** When a spec cannot be mapped to a specific repo, there is no clear home for it. 2. **Agent awareness:** If specs live in an independent "pure" spec repository, agents need to know which code repositories are relevant to each change spec. 3. **Cross-repo consistency:** Specs may differ per repo, so centralizing them does not fully solve the problem. ## User Story > "To a significant degree, we work with microservice-based projects and usually maintain separate repositories for frontend and backend. This makes it difficult for us to map a feature / change to one specific repository." > > "Where should the spec be maintained when it can't be mapped to a specific repo?" > > "If the specs live in an independent, 'pure' spec repository, how do w