Multi-language monorepo — engine iteration model

[mathieusouflis]

Problem statement

The current engine runs registry.ForSpec(spec) once for a single Spec. In a monorepo with a Go API and a Next.js frontend, each app has its own language and modules. The engine must run per app. We need to design this before building any monorepo or microservices generator.

Proposed solution

Option A — Per-app Spec array
dot init for a monorepo produces one Spec per app. The engine iterates over the array, running ForSpec + Apply for each, scoping the pipeline's write path to the app's subdirectory.

.dot/config.json stores per-app state as a map keyed by app name:

{
  "apps": {
    "api": { "spec": {...}, "commands": {...} },
    "frontend": { "spec": {...}, "commands": {...} }
  }
}

Pros: Clean separation. Each app is independently manageable. Backward compatible (single-app projects remain unchanged — they just have one entry in the map).
Cons: Requires a Context struct refactor and changes to Load/Save.

Option B — Nested Spec
A single top-level Spec with a Children []Spec field. The engine recurses.

Pros: Single Spec type.
Cons: More complex recursion. Harder to scope the write path per child.

Alternatives considered

No response

Area

Core

Additional context

This is a Spec and Context refactor. Resolve early — it affects internal/spec/spec.go, internal/project/context.go, and cmd/dot/cmd_init.go.
Blocks all monorepo and microservices generator work.
See docs/developer-guide/roadmap/open-decisions.md #7.