Mono and participant sets

The first public mental model is mono-run: one repository, one task, one run.

Under the hood, Orcho is moving toward a participant-set model. A run has one or more participating repositories, and every participant needs consistent setup, execution, verification, and delivery coverage.

Why not start with cross-project?

Because cross-project is deeper than the first concept a reader needs.

The simple ladder is:

mono-run
  → companion repository discovered
  → participant set
  → cross-project run

The important invariant is not “cross is special”. The important invariant is:

Orcho must know which repositories participate in the delivery, where their editable checkouts are, and what evidence proves their changes.

That framing keeps mono and cross on the same conceptual foundation.

When cross becomes the right shape

Cross-project mode starts when one feature intent cannot be honestly delivered inside one repository.

Examples:

• an API producer and a web consumer must agree on a payload contract;
• backend, frontend, analytics, and docs must move as one release unit;
• an MCP surface, SDK, or runtime adapter changes together with core behavior;
• each project can pass local tests while the integrated feature is still broken.

At that point, the participant set becomes the operating surface. Orcho plans globally, hands each alias a concrete subtask, then checks the result at the system boundary.

Read Cross-project mode for the full delivery shape.