Context / Problem
Systems built as multiple repos — microservices, frontend/backend/shared-library splits — hold subsets of one larger intent tree, and people struggle to organize LID across them. The lid-coach FAQ (LID-COACH-052) has a good container-repo pattern (system-level HLD in a container repo, sub-repos cloned inside and gitignored, each with its own complete arrow plus an upstream pointer, why-not-submodules), but it's plugin-only and conversational — and it assumes an agent working from the container with everything cloned, which doesn't match how per-service teams actually work.
Proposed change
A first-class guide under the users'-guides segment (parent: #54) teaching the container-repo pattern: rooting system-level intent, per-repo arrows with upstream pointers, the submodules trap, when a monorepo beats the pattern, and — the part the FAQ doesn't cover — working from inside a single sub-repo (what a per-service team needs to know about the container) and cross-repo cascade as convention: how sub-repo owners learn that system-level intent changed, given the overlay is single-repo.
Deferred mechanism questions (parked, not lost)
If real use proves the conventions insufficient, these become separate core/maintenance issues: cross-repo references in index.yaml (blocks/blockedBy across repos), a system-level audit view, /map-codebase over multiple repos.
Acceptance criteria
Scope & non-goals
- Not multi-repo orchestration tooling (clone scripts, meta-repo managers).
- Not prescribing monorepo vs. multi-repo.
Intent touchpoints
New EARS under the users'-guides segment (prefix allocated when the segment lands). Existing: LID-COACH-052 / lid-faq.md multi-repo section (reconcile).
Related
Context / Problem
Systems built as multiple repos — microservices, frontend/backend/shared-library splits — hold subsets of one larger intent tree, and people struggle to organize LID across them. The lid-coach FAQ (LID-COACH-052) has a good container-repo pattern (system-level HLD in a container repo, sub-repos cloned inside and gitignored, each with its own complete arrow plus an upstream pointer, why-not-submodules), but it's plugin-only and conversational — and it assumes an agent working from the container with everything cloned, which doesn't match how per-service teams actually work.
Proposed change
A first-class guide under the users'-guides segment (parent: #54) teaching the container-repo pattern: rooting system-level intent, per-repo arrows with upstream pointers, the submodules trap, when a monorepo beats the pattern, and — the part the FAQ doesn't cover — working from inside a single sub-repo (what a per-service team needs to know about the container) and cross-repo cascade as convention: how sub-repo owners learn that system-level intent changed, given the overlay is single-repo.
Deferred mechanism questions (parked, not lost)
If real use proves the conventions insufficient, these become separate core/maintenance issues: cross-repo references in
index.yaml(blocks/blockedByacross repos), a system-level audit view,/map-codebaseover multiple repos.Acceptance criteria
Scope & non-goals
Intent touchpoints
New EARS under the users'-guides segment (prefix allocated when the segment lands). Existing: LID-COACH-052 /
lid-faq.mdmulti-repo section (reconcile).Related