Cloud orchestration surface for team-scale CLI agents.

The monorepo now contains the first delivery wave for a Linear-like control plane: workspace and issue modeling, typed control-plane API, queue bootstrap, runner-session planning, and a docker-compose local footprint for internal rollout.

Project

Agent Cloud Platform

Linear-like control plane for issue-driven agent runs, direct chat sessions, and execution observability.

Repo policy

Default provider mix: GitHub, GitLab, self-hosted GitLab. Agent runs and direct chat share the same write-capable repo boundary.

Active views

Workspaces, projects, issues, board, direct chat, execution timeline, artifacts, notifications.

Next.js 16

apps/web

Linear-like product shell for workspaces, projects, issues, direct chat, and live execution views.

Issue board and comment surfaces
Direct chat entrypoint
Execution timeline and artifact viewer

Fastify + tRPC

apps/api

Control-plane API for memberships, issue orchestration, repo connections, notifications, and run metadata.

Workspace and project catalog
Typed issue/run procedures
Webhook and integration boundary

BullMQ worker

services/orchestrator

Queue-driven run coordinator that accepts issue/chat work and forwards it into the runner plane.

Retries and staged transitions
Capability-aware agent dispatch
Review and policy gates

Typed runner planner

services/runner

Runner-plane boundary that owns repo workspace mounts, execution policy, and artifact paths for CLI agents.

Repo write boundary
Per-run workspace planning
Future container and PTY execution hooks

Design principles

Foundation constraints already encoded

These principles are shared between the UI shell, API seed data, queue orchestration, and runner planning.

Symphony-derived run model

Issue runs and direct chat sessions share the same event spine, but tenancy, permissions, notifications, and repo connections live in the product layer above the raw runner contract.

Typed control plane first

The first delivery wave keeps every product-facing edge in TypeScript with zod-validated contracts and tRPC as the primary interface between web and API.

Persistent, attributable execution logs

Run metadata and execution artifacts are modeled as first-class entities because the service must preserve reasoning, tool calls, and file edits with issue-level attribution.

Open questions

Default product policy still to lock

The schema keeps the next architecture decisions explicit instead of burying them in prose.

notifications.v1

Should external fan-out start with email, Slack, or inbox-only?

Default: Ship inbox-first and add external fan-out as background workers in the next wave.

merge-policy.default

What is the default autonomous merge policy for new projects?

Default: Keep manual review as the default and allow autonomous merge via per-project policy.

runner-hardening.wave2

When does shared-host isolation need to move to stronger container boundaries?

Default: Keep shared-host for internal rollout and harden isolation before external SaaS onboarding.