# Quickstart

> 저장소 clone, Orca 프로젝트 등록, 에이전트 시작, wake-up 문장, 첫 작은 작업까지의 최소 실행 경로를 문서화합니다.

- Repository: local/master-ops-with-local-mogui-ADE-orchestrator

- Human docs: https://grok-wiki.com/public/docs/local-master-ops-with-local-mogui-ade-orches-0ac7093355f3
- Complete Markdown: https://grok-wiki.com/public/docs/local-master-ops-with-local-mogui-ade-orches-0ac7093355f3/llms-full.txt

## Source Files

- `local-mogui-ade-orchestrator:README.md`
- `local-mogui-ade-orchestrator:docs/public/getting-started.md`
- `local-mogui-ade-orchestrator:docs/assets/wake-up-master.png`
- `local-master-ops:ONBOARDING.md`
- `local-master-ops:onboarding/00-orientation.md`

---

---
title: "Quickstart"
description: "저장소 clone, Orca 프로젝트 등록, 에이전트 시작, wake-up 문장, 첫 작은 작업까지의 최소 실행 경로를 문서화합니다."
---

`mogui-ADE-orchestrator`의 최소 시작 경로는 런타임 저장소를 clone하고, 그 폴더를 Orca 프로젝트로 등록한 뒤, Orca 터미널 안에서 선택한 agent CLI를 실행해 `master-ops/ONBOARDING.md` 라우터로 진입하는 흐름이다. 설치 인터뷰는 별도 ops 저장소를 만들고, workspace seat를 기록하며, Generation 1 Master를 Orca orchestration 경로로 spawn한다.

## 전제 조건

첫 실행 전에 모든 항목을 완성할 필요는 없지만, Step 0 preflight가 아래 표면을 실제로 측정한다. `FAIL`은 founding 진행을 막고, `WARN`은 실행은 가능하지만 비용이나 제한을 명시한다.

| 항목 | 확인 명령 또는 신호 | 실패 시 의미 |
| --- | --- | --- |
| Orca CLI | `orca status --json` | Orca runtime이 준비되지 않아 Master seat와 orchestration을 만들 수 없다. |
| Orca orchestration Run | `orca orchestration run-current --json` | 현재 터미널에 non-legacy Run이 바인딩되지 않아 task family가 동작하지 않는다. |
| Master agent CLI | `ORCA_AGENT_CLI=<cli> bash scripts/onboarding-preflight.sh` | Master를 실행할 CLI가 `PATH`에 없다. |
| Worker runtime | `command -v codex` 또는 `command -v cursor-agent` | 위임할 executor가 없다. 하나만 있어도 시작은 가능하다. |
| `git`, `gh`, `python3`, `bd` | 각 `--version` 또는 `bd where` | 저장소 운영, PR 경로, Python entrypoint, issue tracker 연결이 불완전하다. |
| Orca skills | `orca-cli`, `orchestration` skill artifact | agent가 Orca 표면을 안정적으로 호출할 수 없다. |
| Redaction rules | `REDACTION_EXTRA_PATTERNS` 또는 `~/.config/redaction-extra.txt` | publish gate가 조직별 민감정보 규칙을 판단할 수 없다. |

<Note>
`bash scripts/onboarding-preflight.sh --fix`는 설치 가능한 일부 의존성 설치와 `ctx` local history index 설정을 시도할 수 있다. 처음에는 no-flag preflight로 측정한 뒤, 설치 동의를 별도로 결정한다.
</Note>

## 최소 실행 경로

<Steps>
<Step title="저장소를 clone한다">

```console
$ git clone https://github.com/baksohyeon/mogui-ADE-orchestrator
$ cd mogui-ADE-orchestrator
```

이 clone은 installer이자 runtime source다. Founding이 끝나면 workspace governance는 새 ops 저장소에 기록되고, 이 clone 자체가 영구 Master seat가 되는 것은 아니다.

</Step>

<Step title="Orca에 폴더를 등록한다">

Orca UI에서 프로젝트를 추가하고 workspace root 또는 이 clone 폴더를 선택한다. CLI가 등록되어 있으면 같은 작업을 터미널에서도 실행할 수 있다.

```console
$ orca repo add --path <path-to-folder>
```

등록 후 Orca 안에서 터미널을 열고 `pwd`가 installer를 시작할 checkout인지 확인한다. multi-repo workspace에서는 Master가 개별 제품 저장소 worktree가 아니라 workspace root의 folder workspace에 앉아야 한다.

</Step>

<Step title="Orca 터미널에서 agent CLI를 시작한다">

선택한 Master host CLI를 실행한다. 가장 많이 검증된 host는 `claude`지만, onboarding은 `ORCA_AGENT_CLI`로 선택한 CLI를 기록한다.

```console
$ claude
```

다른 CLI를 쓰는 경우에도 실제로 계속 사용할 binary 이름을 선택해야 한다. preflight는 그 이름이 `PATH`에서 해석되는지 확인한다.

</Step>

<Step title="wake-up 문장만 입력한다">

구체적인 작업을 주지 말고 짧은 wake-up 문장만 입력한다.

```text
일어나라 마스터여
```

```text
Wake the master.
```

라우터가 의존하는 것은 문장의 의식적 표현보다 “아직 구체 작업이 없다”는 상태다. agent는 installer로 동작하며 `master-ops/ONBOARDING.md`를 읽고 session mode부터 분류한다.

</Step>
</Steps>

## Onboarding에서 선택하는 것

처음 질문은 session mode다. 새 workspace라면 `Founding`을 선택한다. 이미 ops 저장소나 lineage가 있으면 `Reverify` 또는 `Upgrade` 경로로 가야 하며, Founding을 다시 실행해 두 번째 Master를 만들면 안 된다.

| 결정 | 기록되는 내용 |
| --- | --- |
| Workspace root | Master가 관리할 absolute root path. agent가 후보를 스캔해 대신 고르지 않는다. |
| Repository inventory | workspace root 바로 아래의 Git 저장소 목록. 기본은 측정된 모든 child repository 포함이다. |
| Ops repository | workspace governance, lineage, runbook, tracker 상태를 담는 별도 저장소다. |
| Master callsign | 살아 있는 Master session을 부를 짧은 이름이다. `Master`는 역할명이다. |
| Model and runtime config | `config/instance-runtime.json`, `config/model-tier-policy.json`에 instance-owned 값으로 기록된다. |
| Gen-1 spawn 승인 | Orca Run, Task, Dispatch를 만들고, placement 검증된 터미널 하나를 생성한다. |

## 성공 판정

Founding 성공은 “installer가 완료라고 말했다”가 아니라 다음 신호로 판단한다.

| 신호 | 기대 상태 |
| --- | --- |
| Master pane | Orca에서 workspace seat에 정확히 하나의 Generation 1 Master terminal이 있다. |
| Role State | 새 Master가 callsign, active role, Role Lock 상태를 선언한다. |
| Model identity | 측정 가능, unavailable, unsupported 중 하나로 보고된다. 추측값으로 채우지 않는다. |
| Placement evidence | host pane/worktree selector, cwd, session artifact namespace가 workspace root와 맞는다. |
| Lineage | `docs/lineage/MASTER-LINEAGE.md`에 Generation 1 항목이 append된다. |
| Completion | founding Task와 Dispatch가 `worker_done`으로 완료된다. |

<Warning>
multi-repo workspace의 Master가 제품 저장소 worktree 아래에 보이면 misplacement로 다룬다. 새 Founding을 반복하지 말고 ops 저장소의 recovery 또는 succession 경로를 사용한다.
</Warning>

## 첫 작은 작업

첫 작업은 편집 없는 확인 작업으로 시작한다. 목적은 Master가 proposal, approval, dispatch, evidence acceptance를 분리하는지 보는 것이다.

```text
<repo-name> 저장소에서 README.md를 열고 최상위 section heading만 나열해 주세요.
파일은 수정하지 마세요. 결과물은 heading 목록입니다.
```

정상 흐름은 다음과 같다.

1. Master가 대상 저장소, 허용 surface, acceptance criteria, evidence를 좁은 contract로 다시 쓴다.
2. 사용자가 contract를 확인하고 실행을 승인한다.
3. Master가 Orca orchestration으로 Task를 만들고 worker terminal에 Dispatch를 attach한다.
4. worker가 artifact와 evidence를 반환한다.
5. Master가 worker의 `done` 주장을 직접 검증한 뒤 accept 또는 reject를 말한다.

이 경로는 provider-specific plugin 호출이 아니라 Orca Run, Task, Dispatch, `worker_done` mailbox를 사용하는 vendor-neutral orchestration 표면이다. 선택한 agent CLI와 skill pack은 교체 가능한 실행 계층이며, workspace 사실과 governance는 파일, Git 저장소, issue tracker에 남는다.

## 자주 막히는 지점

| 증상 | 먼저 확인할 것 | 처리 |
| --- | --- | --- |
| `orca` 명령이 없다 | Orca Settings의 CLI 등록 | `Settings → Orca CLI → Shell command`를 켠다. |
| preflight가 `BLOCKED`로 끝난다 | `FAIL` label | 각 label을 고친다. `PREFLIGHT_WAIVE=<label>`은 의미를 이해한 경우에만 쓴다. |
| Run이 없다고 나온다 | `orca orchestration run-current --json` | `orca orchestration run-create`로 현재 터미널에 Run을 바인딩한다. |
| `Unavailable worktree`가 보인다 | Master가 folder workspace에 있는지 | folder workspace Master에서는 정상 label일 수 있다. path 대신 `worktreeId`를 본다. |
| 두 번째 Master가 보인다 | `orca terminal list`와 lineage | duplicate Master incident로 처리한다. Founding을 반복하지 않는다. |
| 첫 worker가 완료를 말했지만 Master가 accept하지 않는다 | artifact와 evidence | worker의 완료 보고는 claim이다. acceptance는 Master의 재검증 결과다. |

## Next

<CardGroup>
  <Card title="설치" href="/installation">
    preflight 의존성, Orca CLI 등록, agent CLI, Beads, redaction rules를 먼저 점검한다.
  </Card>
  <Card title="온보딩 모드" href="/onboarding-modes">
    Founding, Reverify, Upgrade, Template improve의 진입 조건과 spawn 금지 조건을 구분한다.
  </Card>
  <Card title="Orca 객체 모델" href="/orca-object-model">
    Project, workspace, worktree, terminal, Run, selector와 placement 실패 조건을 확인한다.
  </Card>
  <Card title="작업자 위임" href="/dispatch-workers">
    contract, dispatch gate, Orca task-create, worker completion, acceptance 재검증 흐름을 따라간다.
  </Card>
  <Card title="문제 해결" href="/troubleshooting">
    preflight `BLOCKED`, Orca CLI 미등록, duplicate master, model probe undecidable 같은 증상별 조치를 본다.
  </Card>
</CardGroup>
