Production container topology — multi-container + resource limits

Context

Sub B of Epic #11720 (Cloud Agent OS Deployment Readiness). MVP-critical. Blocked-by D0 #11721 — needs the topology + scheduler-task-taxonomy decision first.

The Problem

Once D0 decides the target deployment topology, the multi-container structure must be implemented. Today ai/deploy/docker-compose.yml is a stale 3-service KB/MC/Chroma baseline with no per-container resource limits — devops cannot govern RAM/CPU per service, which is the concern motivating the mission.

The Fix

Implement the D0-decided container topology: the multi-container service structure (KB, MC, Chroma, the cloud-safe scheduler/orchestrator profile, model-provider, reverse proxy — per the D0 ADR's decided shape); per-container resource limits (deploy.resources / mem_limit / cpus); the profile variants (baseline / minimal-cloud / local-model-PoC / production-ingress / managed-service) per the D0 ADR. The cloud scheduler profile excludes the orchestrator's local dev-sync lanes (per D0's task taxonomy).

Acceptance Criteria

• Multi-container topology implemented per D0's ADR.
• Per-container resource limits declared (devops can cap RAM/CPU per service).
• Profile variants expressible (compose profiles / overrides).
• The cloud-safe scheduler profile excludes local dev-sync lanes.

Out of Scope

• The reference compose-file authoring (Sub C).
• The topology DECISION (D0 #11721).

Related

Parent #11720 · blocked-by #11721 (D0) · Origin Discussion #11718 §5 Sub B + the D1 Double Diamond matrix.

Origin Session ID

8e1dc8ca-b5a5-4479-b3cf-31918eb4a5b2