Repository boundaries
Product Compass exists because different repositories should have different jobs.
| Space | Owns | Should avoid |
|---|---|---|
| Meridian core | Tools, standards, schemas, validators, generators, shared packages, agent guidance, and control-plane rules. | Private product strategy and hard-coded references to external product repositories. |
| Product repositories | Code, local docs, goals, generated facts, architecture notes, and project-specific metadata. | Cross-project synthesis that belongs outside the project. |
| Local workspace overlays | Ignored local checkouts such as projects/ and clients/. | Anything that must be reproducible from the shared repository. |
| Meridian Hub | Live operational visibility, provider status, sync logs, deployments, build state, and current health. | Becoming the authoritative source for long-lived project facts. |
| Product Compass | Cross-project synthesis, capability maps, reuse opportunities, AI context, and portfolio knowledge. | Becoming the source of truth for facts owned by individual repositories. |
Client boundary
Client knowledge should be isolated from personal product knowledge.
Client work can inspire generic reusable patterns, but client-specific facts, strategy, code details, credentials, commercial context, and private delivery information should not flow into this personal product compass.