Orcho Docs Map by Operator Path

Read top down

Do not start from every subsystem at once. Start with one run, then move down the ladder only when the current layer raises a concrete question: quality, measurement, control, extension, design, or raw contracts.

startoperatequalitymeasurecontrolbuilddesignreference

Run one taskMeasure progress

one run firstquality nextcontracts last

Depth axisStart -> operate -> improve -> measure -> control -> build -> design -> reference.Domain axisRun control, profiles, gates, evidence, workspaces, MCP, prompts, runtime adapters.Reading ruleMove deeper only when the current layer creates a real operating question.

docs routetop down

01  can I run one task?
  -> quickstart, first run, watch the stream

02  how do I operate delivery?
  -> lifecycle, anatomy, delivery control

03  how do I improve quality?
  -> profiles, gates, false-ready, receipts

04  how do we measure progress?
  -> leaders, cost, runtime economics, real run, security

05  how do tools control it?
  -> MCP, CI, observe, decide

06  how do we adapt it?
  -> workspaces, plugins, skills, prompts

07  why is it designed this way?
  -> architecture

08  what is the exact contract?
  -> config, profiles, artifacts, events

Read by depth first. Use domain slices only when you already know the subsystem you need.

01Start simpleInstall, run one mono task, watch live output, and read the result.02Operate deliveryUse lifecycle, plans, handoffs, recovery, and delivery decisions on real work.03Improve qualityUse profiles, gates, receipts, and evidence to catch false-ready work.04Measure and governEvaluate quality, cost, adoption, proof, and operational risk over a run window.05Control surfacesLet MCP-aware clients and CI start, observe, diagnose, and decide runs.06Build and extendTune projects, skills, prompts, profiles, workspaces, and runtime adapters.07ArchitectureUnderstand the engine model, state, gates, isolation, prompts, and MCP anatomy.08ReferenceUse raw config, profile, CLI, artifact, and event contracts.

Start simple

Use this layer when you are still deciding whether Orcho makes sense or trying to complete the first run.

Question	Read
What is the smallest useful path?	Quickstart
Which install path should I use?	Installation methods
What is Orcho?	What is Orcho?
Can I understand the idea in one run story?	Orcho in 5 minutes
What happens in one project?	Your first run
What should I watch while it runs?	Watch the run
What did the run leave behind?	Read the result
Something failed early. Now what?	Troubleshooting

Operate delivery

Use this layer when Orcho is no longer a trial command and you need to move real delivery forward.

Operating need	Read
Understand the lifecycle	Run lifecycle
Read a deeper feature-shaped run	Run anatomy
Decide whether a retained run should land	Delivery control
Understand plan contracts and subtask DAGs	Plan contract and DAG
Handle pauses and advice	Handoffs and advisors
Move forward after rejected final acceptance	Correction follow-ups
Choose resume versus follow-up	Recovery and resume

Improve quality

Use this layer when the goal is better delivery quality, not lighter prompting.

Quality question	Read
How should workflow depth match task risk?	Profile semantics
Can Orcho recommend a profile?	Profile advisor
What makes a gate trustworthy?	Gates and verification
How does Orcho catch work that says done too early?	False-ready delivery
How do checks become durable proof?	Verification receipts
What evidence exists after the run?	Evidence bundle

Measure and govern

Use this layer when the question is whether agent-assisted delivery is improving over a team, project, or run window.

Evaluation question	Read
What should leaders measure first?	Measure and govern
How should a technical leader evaluate Orcho?	For technical leaders
Where did the workload and cost go?	Cost accounting
How should expensive and lower-cost runtimes be mixed?	Runtime economics
What does one complete real run prove?	A real run, annotated
What stage and scope is the project in?	Project status
What crosses the data-flow boundary?	Security and privacy

Control surfaces

Use this layer when a CLI-only workflow is not enough and another tool needs to start, observe, diagnose, or decide runs.

Control need	Read
Can my AI client drive Orcho for me?	Let your agent drive it
How do I set up MCP?	Start with MCP
When is an LLM captain worth the overhead?	LLM captain mode
What tools does MCP expose?	MCP control surface
What recipes and resources exist?	Workflow recipes and resources
How does a client observe a run?	Observe a run
How do experts build the loop?	Expert MCP control loop
How do runs work without prompts?	Unattended runs and CI

Build and extend

Use this layer when you are shaping Orcho for a repository, team, or extension.

Builder need	Read
Understand workspace boundaries	Workspace model
Grow from mono-run to participant sets	From mono-run to participant sets
Coordinate one feature across repositories	Cross-project mode
Teach Orcho a project	Project tuning and plugins
Turn native checks into durable gates	Scheduled verification setup
Design a cost-aware gate portfolio	Quality gate strategy
Route subtasks to domain capabilities	Skill registry
Understand prompt composition	Prompt engine
Tune workflow depth and gates	Profiles and gates
Connect worker CLIs and wrappers	Runtime adapters

Architecture

Use this layer when the operating surface raises a “why is it built this way?” question. These pages are design narratives; exact schemas live in reference.

Design question	Read
What are the engine’s first-class concepts?	The engine model
Why can runs be resumed and repaired safely?	Runs as recorded state
What makes a gate verdict trustworthy?	Gates and verification
Why do runs get their own checkout?	Isolation and delivery boundary
How are worker prompts composed and protected?	The prompt plane
How does one intent span several repos?	Cross-project projection
How is the MCP server structured?	MCP control plane anatomy

Reference contracts

Use reference pages after the operating model is clear.

Contract need	Read
Configure Orcho	Configuration
Inspect profile modes and schema keys	Profiles
Understand run statuses	Run state reference
Find the command surface	CLI
Inspect run files	Artifacts
Consume the event stream	Events

Domain slices

The same docs can also be read by subsystem once you know your problem surface.

Run controlLifecycle, delivery decisions, plan/DAG, handoffs, follow-ups, resume.Profiles and gatesThe semantic plane, verification boundary, readiness policy, receipts.MeasurementQuality, adoption, runtime economics, cost, proof, and risk over a run window.WorkspacesRun state, project boundaries, participant sets, isolation choices.Cross-project deliveryOne feature intent split across repo boundaries and returned to one gate.MCP controlTyped client control for start, observe, diagnose, and decide.Prompt enginePrompt parts, protected contracts, project context, and turn payloads.Skill registryPortable capability packages, trust policy, and subtask routing.Worker runtimesWorker CLIs, GLM-compatible wrappers, phase routing, adapter boundaries, and cost signals.System designEngine model, state, gates, isolation, prompt plane, and MCP anatomy.

Rule for going deeper

Move to the next layer only when the current layer raises a concrete question:

• “Can I run it?” -> Start simple.
• “What do I do with this run?” -> Operate delivery.
• “How do we make the result more trustworthy?” -> Improve quality.
• “Are we getting better?” -> Measure and govern.
• “How do other tools control it?” -> Control surfaces.
• “How do we adapt it to our projects?” -> Build and extend.
• “Why is it built this way?” -> Architecture.
• “What exactly is the contract?” -> Reference.

That keeps the docs from becoming a wall while still giving deep readers a clear path down.