# Workspace And Repository Strategy

## Current Position

Open Orchestra uses npm workspaces while the package, web console, public site,
and VS Code extension are still evolving together.

This keeps local development coherent:

- one root install;
- one lockfile;
- one build/test surface for release validation;
- shared issue, workflow, and evidence history;
- simpler refactors while contracts are still changing.

## Future Direction

Move workspace packages to independent repositories when their release cadence,
ownership, or distribution channels become meaningfully independent.

Likely split candidates:

- `site`: public/docs site, deployable independently.
- `web-console`: React/Vite console if it becomes a standalone app or SaaS
  frontend.
- `extensions/vscode-open-orchestra`: VS Code marketplace extension with its own
  packaging, versioning, and release checks.
- SaaS services or prompt registry components when they need separate runtime,
  scaling, security, or deployment ownership.

## Split Criteria

Consider extracting a workspace when at least one is true:

- it has a different release cadence from the CLI package;
- it has a different deployment target or CI/CD pipeline;
- it needs separate access control, secrets, or infrastructure ownership;
- it has a distinct package registry or marketplace release process;
- changes frequently require isolated review or rollback;
- its dependency graph materially conflicts with the root package;
- external contributors should work on it without touching CLI internals.

## Non-Goals For Now

- Do not split repositories before package boundaries and contracts stabilize.
- Do not duplicate shared workflow rules across repos manually.
- Do not move code only to reduce directory count.

## Migration Guardrails

Before extracting a workspace:

- define the public contract between the CLI and the extracted package;
- move shared types or protocol definitions into a versioned package or schema;
- preserve issue/task traceability across repos;
- keep release notes and compatibility expectations explicit;
- ensure local/offline development remains possible;
- keep Open Orchestra managed instruction blocks project-local and non-invasive.

## Decision

Use npm workspaces now. Plan for independent repositories later, once package
boundaries, release cadence, ownership, and deployment needs justify the split.