Add mono-repo consideration to ARCHITECTURE_V2.md open questions
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -487,3 +487,16 @@ New node (straylight) takes over as master and hosts core infrastructure:
|
|||||||
|
|
||||||
5. **straylight hardware**: What hardware is straylight? Does it run
|
5. **straylight hardware**: What hardware is straylight? Does it run
|
||||||
NixOS or Debian? Does it use rootless podman like rift?
|
NixOS or Debian? Does it use rootless podman like rift?
|
||||||
|
|
||||||
|
6. **Mono-repo for core infrastructure**: The current layout has each
|
||||||
|
service as a separate git repo under `~/src/metacircular/`. A
|
||||||
|
mono-repo for core infrastructure (mcp, mcp-master, mcns, metacrypt,
|
||||||
|
mcr, mc-proxy, mcdsl) would simplify coordinated changes (e.g., a
|
||||||
|
proto change that touches agent + CLI + mc-proxy client), eliminate
|
||||||
|
the `uses_mcdsl` build flag / vendoring, enable a single CI pipeline,
|
||||||
|
and allow atomic platform versioning (one tag per release). Non-core
|
||||||
|
application services (exo, mcq, mcdoc, sgard, kls, mcat) would
|
||||||
|
remain as separate repos with independent release cadences. This is
|
||||||
|
a large migration best tackled after straylight is running and the
|
||||||
|
master exists, when the build/deploy pipeline is already being
|
||||||
|
reorganized.
|
||||||
|
|||||||
Reference in New Issue
Block a user