OpenRig + Herdr
글로벌 MBP 실습

기능

격리 파일럿과 글로벌 운영의 차이를 이해한다. 프로그램은 같고(0.6.6), 데몬이 어느 HOME과 어느 상태 폴더로 떠 있느냐가 다르다.

	격리 파일럿 (rig-mbp)	글로벌 (rig)
HOME / 상태	openrig-mbp/runtime-home / openrig-mbp/state	~ / ~/.openrig
Claude·Codex 설정	빈 claude-home, 복사한 Codex 인증	평소 설정 경로 참조; 실제 적용은 G단계 검증
kernel	꺼 둠 (--no-kernel)	켜짐 (advisor·operator·queue)
Herdr	세션 openrig-mbp, prefix Ctrl-a	기본 세션, prefix Ctrl-b
목적	OpenRig 자체의 동작 확인	내 글로벌 기능이 OpenRig 안에서 도는지 검증

명령

command -v rig
which -a rig
rig --version
rig status
rig ps --nodes -A --no-cleanup --json
lsof -nP -iTCP:7433 -sTCP:LISTEN
rig terminal status
herdr --version

위 lsof에서 확인한 실제 listener PID를 DAEMON_PID에 넣어 열린 DB를 확인한다.

lsof -p DAEMON_PID -Fn | rg 'openrig.*sqlite'

~/.openrig/openrig.sqlite이면 글로벌 상태 DB다. 출력이 없으면 확인되지 않은 것으로 기록한다. 파일럿 DB가 보이면 어느 팀이 사용 중인지부터 확인하고, 실습 도중 데몬을 자동 교체하지 않는다. 이 페이지 아래의 격리 파일럿 기록은 당시 환경의 참고 자료다.

설치가 필요한 새 MBP에서만

현재 MBP는 이미 설치돼 있어 재설치하지 않는다. 새 기기는 공식 시작 가이드를 확인하고, 에이전트에게 다음처럼 요청한다.

MacBook Pro에서 글로벌 OpenRig와 Herdr 실습을 준비하려고 한다.
command -v와 버전으로 rig, herdr, node, tmux, claude, codex의 설치 여부를 먼저 조사해라.
기존 rig-mbp 래퍼가 있으면 실제 CLI 설치 경로와 환경 분리 방식을 설명해라.
설치가 필요한 항목만 현재 공식 문서의 출처와 설치 명령을 제시해라.
rig-mbp 격리 프로필을 새로 만들지 마라. 기존 설정·인증은 보존하고 값을 출력하지 마라.
설치 계획과 setup 계획을 구분하고, daemon·kernel·starter 기동은 별도로 설명해라.

통과 기준: 설치 경로·버전·DB 경로·rig 목록을 대조하고, 단일 CLI와 두 실행 프로필의 차이를 설명할 수 있다.

기능

kernel은 기본 기동 과정에서 관리하는 운영 팀이다. 항상 실행·정상 상태라고 보장되지는 않는다. advisor.lead(Claude)는 의도를 정리하고, operator.agent(Codex)는 OpenRig 운영을, queue.worker(Codex)는 stream의 queue 분류를 맡는다. operator.human은 rig tui를 사용하는 터미널이다. 실제 역할·준비·lifecycle 상태를 함께 읽는다.

명령

rig ps --nodes --rig kernel
rig capture advisor-lead@kernel --lines 40

화면 B에서 herdr로 접속한 뒤, 글로벌 workspace 목록에 kernel이 없으면 화면 A에서 한 번 연결한다.

rig terminal open kernel --provider herdr --json

advisor 입력창 프롬프트

요청자: 구요한. OpenRig 실습 K다.
너는 kernel의 advisor.lead다. rig whoami --json으로 신원을 확인해라.
지금 떠 있는 rig와 seat를 rig ps --nodes -A --no-cleanup --json으로 확인하고, starter 팀을
/Users/사용자이름/DEV/openrig-global-test 에 띄우려면 어떤 절차가 필요한지 설명해라.
아직 실행하지는 말고, 실행을 맡길 대상(operator.agent)과 명령을 제안만 해라.

통과 기준: advisor가 자기 신원과 kernel 구성을 답했고, 직접 실행과 operator 위임을 구분해 제안했다. kernel이 starter를 대신 띄우게 할지, 화면 A에서 직접 rig up을 할지는 사용자가 정한다.

명령

mkdir -p /Users/사용자이름/DEV/openrig-global-test
cd /Users/사용자이름/DEV/openrig-global-test
git init -q
rig ps --rig starter --json

오류가 나면 원인을 확인한 뒤 진행한다. starter가 없을 때 아래 계획과 실행을 순서대로 한다. 이미 있으면 재생성하지 말고 기존 cwd·seat를 확인한다. 중지된 기존 팀의 재개는 11단계를 따른다.

rig up starter --cwd /Users/사용자이름/DEV/openrig-global-test --plan
rig up starter --cwd /Users/사용자이름/DEV/openrig-global-test
rig ps --nodes --rig starter --json
rig whoami --session dev-build@starter --json

계획과 실행에 같은 --cwd를 명시했다. 출력에서 두 seat의 실제 cwd를 확인한다. --non-interruptive는 full bypass의 초기 경고를 받아들이는 rig별 저장 선택이므로 기본 실습에 붙이지 않는다. 현재 권한은 G단계에서 확인한다.

무엇을 읽나

• rig: starter의 rig ID (이후 10·11단계에서 사용 — 아래 STARTER_RIG_ID에 대입).
• seat: dev.build·dev.review가 running·ready인가. 실제 seat 주소가 dev-build@starter와 다르면 이 노트의 주소를 실측값으로 읽는다.
• whoami --session: 지정 주소의 조회 결과다. 에이전트 API 권한 검증과 같지 않다.

통과 기준: rig ID·두 seat 주소·runtime·준비 상태를 기록했다.

먼저 starter 화면 연결

1단계에서 두 seat의 ready를 확인한 뒤, 2단계의 ‘화면 A — 연결 대상 확인’부터 ‘화면 B — Herdr 접속’까지 먼저 수행한다. 기존 starter workspace가 있으면 그것을 선택하고, 없을 때만 rig terminal open starter --provider herdr --json을 한 번 실행한다. Herdr에서 Ctrl-b → w로 starter를 골라 build pane에 들어온 뒤 아래 프롬프트를 보낸다. G단계가 끝나면 2단계의 LAB-02-READY 프롬프트로 이어간다.

기능

이번 전환의 핵심 단계다. 설정 파일의 존재와 이번 seat에서 실제로 적용된 기능을 나눠 기록한다. 기존 hooks를 임의로 실행·수정하지 않고, 평소 설정에 의한 반응만 관찰한다. 메모리 본문·인증값·전체 환경 변수·개인 MCP 검색 결과는 실습 화면에 출력하지 않는다.

실습 전 사람이 할 것

• 확인할 스킬 하나와 읽기 전용 MCP 도구 하나를 고른다. MCP는 실습용 공개 자료만 대상으로 한다.
• 화면에 표시된 권한 모드와 harness 설정·실행 인자를 대조한다. 한국어 응답만으로 CLAUDE.md 적용을 입증하지 않는다.
• 클립보드 hook을 확인하려면 중요한 내용을 먼저 다른 곳에 보관한다. 아래 표식 비교는 선택 실습이다.

화면 B — dev-build@starter 입력창 프롬프트

요청자: 구요한. OpenRig 실습 G다. 파일은 수정하지 마라.
다음을 하나씩 직접 확인하고 표로 보고해라. 확인할 수 없으면 "미확인"이라고 써라.
1. 현재 권한 모드와 확인 근거. 설정의 기본값과 이번 세션의 실제 모드를 구분해라.
2. 내가 선택한 스킬 [이름]의 현재 세션 사용 가능 여부와 로드 근거.
3. 내가 선택한 읽기 전용 MCP [도구]로 실습용 공개 자료 [질의]를 한 번 조회해라.
   도구 이름, 호출 성공 여부, 결과 건수만 보고하고 개인 자료는 출력하지 마라.
4. 이번 세션에 적용되는 전역·프로젝트 지침 파일의 경로와 적용 확인 근거.
5. 자동 메모리 경로의 존재 여부. 내용을 읽었다는 추측이나 원문 출력은 하지 마라.
6. printf '%s\n' "$HOME" 및 pwd를 직접 실행해라.
7. rig whoami --json으로 seat 신원을 확인해라. 명령 실패는 그대로 기록해라.
마지막 코드 블록에는 LAB-G-CLIP-20261009만 넣고 대기해라.

대괄호는 실제 선택으로 바꾼 뒤 보낸다. 알려지지 않은 hook 명령은 실행하지 않는다.

화면 A — 선택: clipboard hook 표식만 비교

위 응답 직후 실행한다. 기존 클립보드 내용은 화면에 출력하지 않는다.

if pbpaste | rg -q -F 'LAB-G-CLIP-20261009'; then
    printf '실습 표식 일치\n'
else
    printf '실습 표식 미확인\n'
fi
rig capture dev-build@starter --lines 60

표식 일치·응답 시각·해당 seat hook 로그가 대응할 때만 이번 Stop hook의 실행 근거로 기록한다. 다른 세션의 자동 복사나 수동 복사와 구분한다. 음성 알림도 seat·시각 대응을 확인한다. 기존 백업 폴더가 있다는 사실은 이번 PreCompact 실행 증거가 아니며, compact가 발생하지 않았으면 미관찰로 남긴다. SessionStart도 기동·재개 시 실행될 것으로 예상되는 설정과 실제 로그를 구분한다.

Codex seat도 확인

dev-review@starter에서도 1–7을 확인하되 Codex의 지침·메모리·MCP 경로와 지원 기능에 맞춰 읽는다. Claude hooks가 Codex에서도 작동한다고 전제하지 않는다. clipboard 표식은 Claude 실습과 구분한다.

통과 기준: 각 항목을 "동작 / 동작 안 함 / 미확인 / 지원 대상 아님"으로 기록하고 근거를 연결했다. 일부 기능이 미확인이어도 그 범위를 알면 다음 파일 실습을 진행할 수 있다.

결과에 따른 후속 결정

• 불편한 hook은 이번 seat의 이벤트·시각·증상을 먼저 기록하고, 적용 범위를 확인한 뒤 별도 수정안을 만든다. 이 실습을 위해 글로벌 권한을 자동 확대하거나 hook을 일괄 끄지 않는다.
• 전역 설정 전체를 물려주는 것이 과하면 rig 전용 설정 폴더를 둔다. seat의 CLAUDE_CONFIG_DIR을 별도 폴더로 지정하고, 필요한 스킬·rules·CLAUDE.md만 복사하거나 symlink한다. 볼트의 .claude/ symlink 구조와 같은 방식이다. 이 방식은 G단계 결과를 보고 설계하며, 이번 전환에서는 아직 만들지 않았다.

화면 A — 연결 대상 확인

rig terminal status
herdr status server --json
herdr workspace list
herdr pane list

글로벌 Herdr에는 기존 개인 workspace도 함께 보일 수 있다. starter workspace가 없으면 한 번만 연결한다.

rig terminal open starter --provider herdr --json

이 명령은 기존 seat를 붙이는 표시 workspace를 만든다. 작업자를 새로 띄우지 않으며, 반복하면 표시 workspace가 중복될 수 있다.

화면 B — Herdr 접속

herdr

Ctrl-b를 누르고 손을 뗀 뒤 w를 눌러 workspace 선택기를 열고 starter workspace를 고른다. dev.build pane에서 Claude 대화를 확인한다.

화면 B — build 입력창 프롬프트

요청자: 구요한. OpenRig 실습 02다.
파일을 수정하지 말고 LAB-02-READY라고 답해라.
pwd, node --version, command -v node를 직접 실행하고 결과를 보고해라.
대화 화면이나 환경에서 확인할 수 없는 모델명·권한은 추측하지 마라.
확인 후 다음 지시를 기다려라.

통과 기준: Herdr 안의 Claude 화면에서 표식이 보이고, 작업자가 직접 확인한 cwd가 /Users/사용자이름/DEV/openrig-global-test다. pane 메타데이터의 cwd와 작업자의 실제 cwd를 구분한다. Herdr에서 빠져나오기: Ctrl-b를 누르고 손을 뗀 뒤 q. 작업자와 Herdr 서버는 계속 남는다.

기능

프롬프트로 범위를 지정하고, 실제 파일 작성과 결과 확인까지 요청한다. 주제는 가상의 팀 AI 사용 안내문이다. 아래 다섯 문장은 이 실습을 위한 합성 자료이며 CMDSPACE의 확정 정책이 아니다.

build 입력창 프롬프트

요청자: 구요한. OpenRig 실습 03이다.
작업 경로: /Users/사용자이름/DEV/openrig-global-test
허용 출력: lab-openrig-20261009/source.txt, lab-openrig-20261009/guide.md
이 두 파일이 이미 있으면 덮어쓰지 말고 상태를 보고한 뒤 기다려라.
없으면 폴더를 만들고 다음 다섯 줄을 source.txt에 그대로 저장해라.

1. 외부 AI에는 공개 자료만 입력한다.
2. 고객 원문·개인정보·비밀값은 입력하지 않는다.
3. AI가 만든 사실 주장은 출처를 확인한다.
4. 배포 전 담당자 검토를 받는다.
5. 근거가 없으면 확인 필요라고 표시한다.

이 원문만 근거로 guide.md에 한국어 FAQ 5개를 작성해라.
각 질문은 '## Q1.'부터 '## Q5.'까지 번호를 붙여라.
제목 아래 '가상 실습 자료 — 검토 전 초안'이라고 표시해라.
원문에 없는 벌칙·승인 조직·서비스 이름·보관 기간을 추가하지 마라.
설치, 다른 agent 생성, 범위 밖 수정, commit/push/배포는 하지 마라.
두 파일을 다시 읽고 원문 5개 규칙과 FAQ 수를 확인해라.
변경 파일, 직접 검증한 것, 미확인 사항을 보고하고 기다려라.

사람이 화면 A에서 확인

cat /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/source.txt
cat /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/guide.md

통과 기준: 원문이 정확하고 FAQ가 5개이며, 가상 초안 표시가 있다. “파일을 만들었다”는 응답만으로 체크하지 않는다. 글로벌 환경에서는 스킬(예: 문서 정리 스킬)이 자동 발동할 수 있으므로, 발동했다면 그 이름도 기록한다.

기능

화면 B의 Herdr를 열어 둔 채 화면 A에서 특정 seat에 메시지를 보내고 최근 화면을 조회한다. 3단계가 끝나고 작업자가 입력을 기다릴 때 실행한다.

화면 A — 명령, 화면 B — 도착과 응답 관찰

rig send dev-build@starter '요청자 구요한. 실습 04. lab-openrig-20261009/guide.md만 읽고 파일 끝에 LAB-04-CHECKED를 정확히 한 번 넣어라. 이미 있으면 추가하지 마라. 읽어 확인한 뒤 LAB-04-DONE이라고 보고하고 기다려라. 그 외 파일 수정은 금지한다.' --wait-for-idle 30 --verify
rig capture dev-build@starter --lines 80

--wait-for-idle 30은 보내기 전 idle 대기다. --verify는 전달 뒤 pane 캡처를 돕는 옵션이며, 수신자의 작업 완료 보증이 아니다.

파일 확인

rg -n -F 'LAB-04-CHECKED' /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/guide.md

통과 기준: 전달 결과, 같은 seat의 LAB-04-DONE 응답, 파일의 표식 1개를 각각 확인했다. 이번 send는 queue 작업 등록이 아니다.

build 입력창 프롬프트

요청자: 구요한. OpenRig 실습 05다.
읽기: lab-openrig-20261009/source.txt, lab-openrig-20261009/guide.md
새 출력: lab-openrig-20261009/review.md
review.md가 이미 있으면 덮어쓰지 말고 보고해라.
검토자 역할로 원문 5개 규칙 각각에 대해 반영 여부와 FAQ 번호를 적어라.
원문에 없는 정책이 추가되었는지, FAQ가 5개인지, 가상 초안 표시가 있는지 확인해라.
수정 요구는 구체적인 문장 단위로 적고, 없으면 없다고 써라.
guide.md와 source.txt는 수정하지 마라. 검토 후 대기해라.

검토서를 사람이 읽고 수정할 항목을 골랐다면 다음 프롬프트를 보낸다.

요청자: 구요한. 검토서를 읽고 source.txt와 대조해라.
내가 선택한 수정 항목: [여기에 실제로 선택한 요구를 적기]
선택한 항목 중 원문 근거가 있는 요구만 guide.md에 반영하라.
새 정책을 만들지 말고, 변경 전후와 반영하지 않은 요구의 이유를 보고해라.
source.txt와 review.md는 보존하고, FAQ 5개와 실습 표식을 다시 확인한 뒤 대기해라.

통과 기준: 원문·초안·검토서의 역할이 다르고 변경 이유를 추적할 수 있다. 여기서는 같은 seat의 역할 전환이다. 서로 다른 seat의 검증은 13단계에서 다룬다.

build 입력창 프롬프트

요청자: 구요한. 실습 06의 대화 표식은 LAB-CONTINUE-42다.
파일에는 저장하지 말고 답변에 이 표식을 포함한 뒤 기다려라.

화면 B에서 Ctrl-b → q로 Herdr 접속을 해제한다. 화면 A에서 seat와 Herdr 서버가 남아 있는지 확인한다.

rig ps --nodes --rig starter --json
herdr status server --json

화면 B의 일반 셸에서 다시 접속한다.

herdr

돌아온 build 입력창 프롬프트

직전 실습의 대화 표식을 말해라. 기억하지 못하면 모른다고 해라.
lab-openrig-20261009의 source.txt, guide.md, review.md가 있는지 직접 확인해라.
파일은 수정하지 말고 확인 결과만 보고해라.

통과 기준: 같은 Herdr workspace와 seat 주소, 이전 대화, 파일 존재를 따로 확인했다. 작업자를 끈 적이 없으므로 화면 재접속 실습이다.

화면 B — 도움말·선택·확대

글로벌 설정의 prefix는 기본값 Ctrl-b다. 아래 조합은 prefix를 누르고 손을 뗀 뒤 다음 키를 누른다.

키	기능	이번 실습에서 해볼 것
Ctrl-b → ?	도움말	실제 화면의 키 목록과 이 표 대조
Ctrl-b → w	workspace 선택기	starter·kernel·평소 workspace 사이 이동
Ctrl-b → h/j/k/l	pane 왼쪽/아래/위/오른쪽	build·review pane 사이 이동
Ctrl-b → Tab / Shift-Tab	다음 / 이전 pane	작업자 pane 선택
Ctrl-b → z	현재 pane 확대 / 복원	두 번 눌러 원래 화면으로 복귀
Ctrl-b → n/p	다음 / 이전 tab	tab이 여러 개일 때 이동
Ctrl-b → b	sidebar 표시 전환	workspace·tab 구조 확인
Ctrl-b → q	Herdr 접속 해제	화면만 나왔다 다시 접속

starter는 seat가 2개라 pane 이동을 바로 실습할 수 있다.

prefix 충돌 주의

seat 안쪽 tmux도 기본 prefix가 Ctrl-b다. Herdr에서 Ctrl-b → Ctrl-b를 누르면 literal prefix를 안쪽에 전달한다. 그 뒤 d는 안쪽 tmux detach다. Herdr 전체 접속 해제는 Ctrl-b → q로 구분한다. 이 동작은 설치된 Herdr 0.9.3의 키 계약으로 확인했으며, 이번 글로벌 seat에서 실제 키 입력은 아직 시험하지 않았다. 개인 설정에 override가 있으면 실제 도움말을 따른다.

화면 A — 어떤 작업자에 붙었는지 확인

herdr pane list
herdr pane process-info --pane PANE_ID

PANE_ID는 목록의 실제 값으로 바꾼다. tmux attach -t dev-build@starter 같은 연결 대상이 보이는지 확인한다. pane 라벨이나 agent_status만으로 OpenRig 준비 상태를 결정하지 않는다.

화면 C — OpenRig TUI와 대조

rig tui

topology에서 kernel·starter를 찾아 화면 A의 ps와 대조한다. q로 TUI만 종료한다. kernel의 operator.human seat에 떠 있는 TUI와 같은 화면이다.

종료 키 구분

• Herdr Ctrl-b → q: Herdr 클라이언트 접속 해제.
• OpenRig TUI q: 상태판만 종료.

통과 기준: Herdr 화면 선택·확대·pane 이동·접속 해제와 TUI를 사용하고, 라벨·연결 대상·실제 작업자 상태를 구분했다.

기능

입력 파일을 하나의 재사용 가능한 문맥 묶음으로 만든다. 3·5단계의 파일이 있어야 한다.

명령

rig context list

packs/lab-openrig-20261009가 없을 때만 생성한다.

rig context compose --out packs/lab-openrig-20261009 --from /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/source.txt /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/review.md
rig context show packs/lab-openrig-20261009
rig context preview packs/lab-openrig-20261009

글로벌 기준에서는 ~/.openrig/context/packs/lab-openrig-20261009/에 manifest와 입력 파일 복사본이 저장된다. 원문 변경은 자동 반영되지 않는다. 같은 ref가 있으면 pack_exists로 거부한다.

전달

rig send dev-build@starter --context packs/lab-openrig-20261009 --wait-for-idle 30 --verify

방금 받은 context pack의 두 자료가 각각 무엇인지 말해라.
원문 규칙과 검토 의견을 구분하고, 충돌이 있으면 어느 부분인지 지적해라.
내용을 받지 못했으면 추측하지 말고 그렇게 보고해라. 파일은 수정하지 마라.

통과 기준: pack 내용, 전달된 화면, 자료를 구분한 응답을 확인했다.

기능

RigSpec은 팀 구성, AgentSpec은 에이전트의 자원·시작 지시를 정의한다. starter는 pod 1개(dev)에 Claude build(implementer)와 Codex review(qa)가 있고, build는 시작할 때 guidance/lead-first-move.md를 받는다.

명령

rig specs show starter
rig specs preview starter
rig specs preview kernel
rig specs ls

spec validate는 실제 spec 파일 경로를 받지만, up --plan은 starter 같은 라이브러리 이름도 받는다. rig requirements starter는 이름을 현재 폴더의 파일 경로로 해석해 ENOENT가 날 수 있다 (2026-10-09 실측).

rig daemon status
rig up starter --cwd /Users/사용자이름/DEV/openrig-global-test --plan

up --plan은 데몬이 꺼져 있으면 자동 시작할 수 있다. 이미 starter가 실행 중이면 거부될 수 있으며, 그 결과 자체를 기록한다. 기존 rig에서 여러 seat의 launch 계획을 볼 때는 1단계에서 기록한 ID를 대입한다. 단일 positional node에 --plan을 붙이는 형식은 0.6.6에서 지원하지 않는다.

rig launch STARTER_RIG_ID --seats dev.build,dev.review --plan --json

통과 기준: dev.build와 dev-build@starter의 관계, cwd, 모델 지정(review만 gpt-6-astra)을 설명하고 검증·계획·실행을 구분했다.

기능

팀의 구성 기록과 재구성 점검을 살펴본다. OpenRig 스냅샷을 프로젝트 파일·인증·native 대화를 모두 포함한 전체 백업으로 간주하지 않는다.

명령

작업자가 idle일 때 실행한다. STARTER_RIG_ID는 1단계의 실측값이다.

rig snapshot STARTER_RIG_ID
rig snapshot list STARTER_RIG_ID
rig restore-check --rig starter --json
rig seat handover dev-build@starter --source rebuild --reason practice-preview --dry-run --json

마지막 명령은 seat를 실제로 재구성하지 않는 미리보기다. 13단계의 queue 작업 인계와 다르다.

통과 기준: snapshot ID와 점검 결과를 기록하고, 미리보기와 실제 복구의 차이를 설명한다.

종료 전 build 입력창 프롬프트

요청자: 구요한. 실습 11 종료 준비다.
lab-openrig-20261009/handoff.md에 현재 결과 파일, 확인한 사실,
미해결 항목, 다음에 할 한 가지 작업을 기록해라.
다른 파일은 바꾸지 말고 종료 준비 완료라고 보고한 뒤 기다려라.

화면 A에서 파일 기준선을 기록한다.

cd /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009 && shasum -a 256 source.txt guide.md review.md handoff.md

화면 A — 종료

rig down starter --json
rig ps --rig starter --json

실습 팀 starter만 종료한다. 글로벌 데몬과 kernel은 유지한다. rig daemon stop은 다른 팀의 API·queue·watchdog에도 영향을 주므로 이 기본 실습에 포함하지 않는다.

화면 A — 재개

rig up starter --existing --json
rig ps --nodes --rig starter --json

--existing으로 보존된 starter를 재개한다. 기존 rig ID·cwd를 대조하고 결과에서 resumed인지 새 세션인지 확인한다. rig start --last는 starter 전용 재개 명령이 아니므로 대신 쓰지 않는다. kernel을 내린 뒤 자동 복구된다고 가정하지 않는다.

화면 B — 다시 접속

herdr pane list
herdr

기존 pane이 끊겼으면 seat가 running·ready인지 확인한 뒤 화면 A에서 rig terminal open starter --provider herdr --json을 한 번 실행한다. 글로벌 Herdr는 resume_agents_on_restore가 기본값(true)이므로, Herdr가 자체적으로 에이전트를 되살린 pane과 OpenRig가 재개한 seat가 따로 생기지 않는지 함께 관찰한다.

돌아온 build 입력창 프롬프트

실습을 재개했다. 파일을 수정하지 마라.
이전 대화에서 확인할 수 있는 실습 표식이 무엇인지 말해라.
이후 lab-openrig-20261009/handoff.md를 읽고 실제 파일들과 대조해라.
대화에서 기억한 것과 파일을 읽어서 알게 된 것을 구분해라.
현재 pwd와 node --version을 직접 확인하고 결과를 보고해라.

응답 후 해시를 다시 구해 종료 전 기록과 대조한다.

cd /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009 && shasum -a 256 source.txt guide.md review.md handoff.md

통과 기준: 기존 rig ID·node 유지, resumed 결과, Herdr 재연결, 이전 대화, 파일 해시를 각각 확인했다. SessionStart hook이 재개 때 다시 실행됐는지도 기록한다. 정상 종료 후 재개 성공은 수면·재부팅 복구 성공과 다르다.

지금 바로 가능한 읽기

rig queue list -A --destination dev-review@starter --json

메시지와 작업 의무는 서로 다른 기록이다. 앞선 send 뒤에도 queue는 비어 있을 수 있다.

글로벌 전환으로 달라진 점

파일럿에서는 Codex network_access=false와 workspace 지침 때문에 seat가 daemon API에 접근하지 못해 claim·update가 막혔다. 글로벌 seat는 평소 설정을 쓰므로 이 제약이 없을 수 있다. 실제 가능 여부는 아래 수명주기로 처음 확인한다. --actor·--destination이나 임의 환경 변수로 신원을 대신하지 않는다 (설치된 구현에서 claim의 --destination, update의 --actor는 deprecated·ignored).

운영자 터미널에서 작업 등록

rig queue create --source human:practice --destination dev-review@starter --summary '실습 FAQ 원문 대조 검토' --body-file - --no-nudge --json <<'TASK'
요청자: 구요한. 가상 실습 FAQ를 원문과 대조한다.
읽기 입력: lab-openrig-20261009/source.txt, lab-openrig-20261009/guide.md
허용 출력: lab-openrig-20261009/queue-review.md 한 개.
출력 파일이 이미 있으면 덮어쓰지 말고 보고한다.
완료 기준: 원문 5개 규칙 각각의 반영 여부와 FAQ 번호, 추가 정책 유무,
FAQ 5개 여부, 가상 초안 표시를 검토서에 기록하고 다시 읽어 확인한다.
입력 파일 수정, 설치, 다른 agent 생성, commit/push/배포는 금지한다.
TASK

반환된 ID를 QITEM_ID에 대입한다. --no-nudge이므로 작업자에게 ID를 직접 알린다.

review seat에 줄 프롬프트

작업 ID: [실제 QITEM_ID]
먼저 rig whoami --json으로 관리 seat 신원을 확인해라.
rig queue show QITEM_ID --full --json 으로 작업 본문을 읽어라.
rig queue claim QITEM_ID --json 으로 수락한 뒤, 지정된 파일과 완료 기준에 따라서만 수행해라.
queue-review.md를 다시 읽어 완료 기준을 검증하고, 성공했을 때만
rig queue update QITEM_ID --state done --closure-reason no-follow-on --note '<실제 검증 결과와 파일 경로>' --json
으로 완료 처리해라. 막히면 완료 처리하지 말고 원인과 현재 queue 상태를 보고해라.
다른 작업을 만들거나 권한을 변경하지 마라.

운영자 터미널에서 증거 조회

rig queue show QITEM_ID --full --json
rig queue transitions QITEM_ID --json

통과 기준: 등록 ID, 실제 소유자, 상태 전이, 파일 검증, done 기록이 일치한다. claim이 실패하면 그 오류가 글로벌 전환의 중요한 관찰 결과다.

기능

한 작업자의 역할 전환을 넘어, starter의 서로 다른 두 seat가 분담하고 결과를 인계한다. 파일럿에서는 별도 팀을 설계해야 했지만, starter에는 처음부터 build→review 위임 관계(delegates_to)가 있다.

순서

build 초안 완료 → review 검토 완료 → 사람이 수정 요구 선택 → build 수정. 동시에 같은 파일을 건드리지 않는다.

두 seat를 Herdr에서 나란히 보기

rig ps --nodes --rig starter --json
herdr pane list

화면 B에서 Ctrl-b → w로 starter workspace를 고르고, Ctrl-b → h/j/k/l 또는 Tab으로 build와 review 사이를 이동한다. 각 프롬프트는 해당 작업자의 입력창에만 보낸다.

review 프롬프트 (dev-review@starter)

요청자: 구요한. 독립 검토 실습이다.
lab-openrig-20261009의 source.txt와 guide.md를 읽고 원문 규칙별 충족 여부,
근거 없는 추가 정책, FAQ 수, 가상 자료 표시를 확인해라.
lab-openrig-20261009/review-independent.md만 작성하고 guide.md는 수정하지 마라.
출력 파일이 이미 있으면 덮어쓰지 말고 상태를 보고해라.
각 판단에는 원문 번호와 FAQ 번호를 적어라. 검토 후 대기해라.

build 프롬프트 (dev-build@starter)

lab-openrig-20261009/review-independent.md를 읽고 원문과 대조해라.
사람이 선택한 항목: [실제 선택한 수정 요구]
선택한 항목 중 근거 있는 요구만 lab-openrig-20261009/guide.md에 반영해라.
원문과 검토서는 바꾸지 마라. 변경 전후와 보류 이유를 보고해라.
지정 작업의 완료 기준을 검증한 뒤 대기해라.

선택: queue 인계를 시험하려면 build가 실제 소유한 별도의 진행 중 작업을 먼저 확보하고 그 ID를 BUILD_QITEM_ID에 넣는다. 12단계에서 review가 이미 완료한 QITEM_ID를 재사용하지 않는다. 먼저 build에 아래 프롬프트를 보내 queue 전용 본문을 준비한다.

lab-openrig-20261009/queue-handoff.md가 있으면 덮어쓰지 말고 보고해라.
없으면 별도의 진행 중 build 작업 [실제 BUILD_QITEM_ID]에 대한 검토 인계서를 작성해라.
읽기 입력은 source.txt와 guide.md, 허용 출력은 queue-handoff-review.md 한 개다.
모든 파일 경로는 lab-openrig-20261009/ 아래로 명시해라.
원문 5개 규칙별 FAQ 대응, 추가 정책, FAQ 수, 가상 자료 표시를 확인하는 것이 완료 기준이다.
입력 파일 수정, 다른 작업 생성, 권한 변경은 금지한다고 명시해라.
출력이 이미 있거나 작업 범위가 일치하지 않으면 중단·보고하도록 적어라.
11단계의 복원용 handoff.md는 보존하고, 작성한 본문을 다시 읽어 확인한 뒤 기다려라.

사람이 본문과 해당 작업의 현재 owner·상태를 확인한 뒤, build가 자기 seat에서 실행한다.

rig queue handoff BUILD_QITEM_ID --to dev-review@starter --summary '초안 검토 요청' --body-file /Users/사용자이름/DEV/openrig-global-test/lab-openrig-20261009/queue-handoff.md --json

placeholder를 그대로 실행하지 않는다. 본문에는 읽을 파일·허용 출력·완료 기준을 명시한다. 실제 인계 결과의 작업 ID를 조회해 소유자·전이·완료를 확인한다. 해당 작업이 없으면 위 수동 인계까지만 수행하고 queue handoff는 미실행으로 기록한다.

통과 기준: Herdr에서 서로 다른 두 seat를 확인하고, 각각의 산출물·인계·수정 결과를 기록했다. 사람이 두 메시지를 전달했다면 자동 협업으로 기록하지 않는다.