Workspaces and Monorepos

Workspaces and Monorepos

CNOS has two repo shapes:

• regular mode: one flat .cnos/ tree
• workspace mode: .cnos/workspaces/<id>/...

The intended progression is:

cnos init
cnos workspace enable
cnos workspace add api --package-root apps/api
cnos workspace add web --package-root apps/web

Regular mode first

cnos init creates:

.cnos/
  values/
  secrets/
  env/
  profiles/

This is effectively the shared base layer for a single-app repo.

Convert to workspace mode

When the repo grows:

cnos workspace enable

CNOS converts the flat tree into:

.cnos/
  workspaces/
    base/
      values/
      secrets/
      env/
      profiles/

base is the default shared workspace convention. It is not resolver magic; it is just the standard scaffolded root workspace.

Add child workspaces

cnos workspace add api --package-root apps/api
cnos workspace add web --package-root apps/web

If base exists, CNOS defaults those children to extends: [base].

Resulting manifest shape:

workspaces:
  default: base
  items:
    base: {}
    api:
      extends: [base]
    web:
      extends: [base]

Anchors

Each consuming app or package should get a .cnosrc.yml anchor:

apps/api/.cnosrc.yml

root: ../../.cnos
workspace: api

CNOS resolves from .cnosrc.yml, not by walking upward for .cnos/ directories.

Onboard existing config sources

If the repo still has env or config files:

cnos onboard
cnos onboard --workspace api --env .env.api --materialize

Use onboarding to pull source files into CNOS first, then move app code to direct CNOS reads later.