워커 터미널은 보기만 한다 - 같은 새벽에 정한 규칙들의 근거

모든 리포를 git worktree add로 바꾼 커밋이
3분 뒤 orca worktree create 기본으로 되돌아갔다.
같은 새벽에 워커 터미널을 화면으로는 보기만 한다는 규칙의 근거도 나왔다.
되돌아간 절차는 시각이 겹친다는 추정에 기댔고
남은 규칙은 앱 코드를 열어 본 설명에 기댔다.
다만 남은 쪽도 실행으로 재현한 근거는 아니고
원인으로 확정했다고 적은 리포 설정은 같은 값인데도
리포와 날짜에 따라 다른 결과를 냈다.

문제

10월 3일 새벽 두 시 반, 윈도우 PC의 Orca 화면에서
Hindsight-Crew 아래 워커 터미널이 보이지 않았다.
"원래는 그냥보였었는데 왜달라진거지?"라고 물었고
에이전트가 CLI로 확인한 상태는 이랬다.
터미널은 138번 이슈 워크트리에 그대로 붙어 있었고
리포의 외부 워크트리 표시 설정인
externalWorktreeVisibility는 hide였다.

30분 뒤 둘째 증상이 나왔다.
워커를 worker-release로 놓아줘도 행이 retained로 남았다.
이 글은 두 증상에서 비롯된 결정 세 가지가 각각 무엇에 기댔는지 살펴본다.
에이전트 워커를 앱 화면과 CLI 양쪽에서 다룬다면
같은 문제를 겪을 수 있다.

화면 입력은 워커를 사람 몫으로 넘긴다

지금 남아 있는 규칙은 하나다.
워커 터미널에는 CLI로만 입력하고 화면은 보기만 한다.

에이전트가 처음 내놓은 설명은, 자기가 워커 터미널에 직접 입력했기 때문에
Orca가 그 워커를 사용자 소유로 분류했다는 것이었다.
"혹시 create 안쓰면서 생긴이슈인가?"라고 되묻자
에이전트는 런마다 남은 행을 세어 답했다.

create로 만든 런에도 사람 소유 행이 남았고
final-review를 넣고도 깨끗하게 정리된 런이 있었다.
생성 방식도, final-review 입력도 그것 하나만으로는 결과를 설명하지 못했다.

에이전트는 이어서 이 맥에 설치된 Orca 1.4.199의 코드를 읽었다.
앱 화면의 터미널이 사람의 입력을 감지하면
렌더러가 RPC(원격 호출)를 보내고 처리기가 그 워커 행을
user_owned, retained, 사유 user_takeover로 바꾼다.
이때 출력 아카이브도 함께 지운다.
CLI의 orca terminal send는 이 경로를 거치지 않는다.
에이전트가 반대 사례로 든 것은 10-02 다른 런의 127번 이슈다.
terminal send로 final-review를 넣었는데도 released로 정리됐다.

그날 새벽 네 시, 활성 터미널에 워커가 없는 것을 확인하고
orca orchestration reset --tasks로
59개 런의 워커 행을 0으로 비웠다.
지금 super-auto 스킬 문서는 "워커 터미널에는 CLI로만 입력한다"로 시작한다.
진행을 보고 싶은 사람은 화면을 만지지 말고 보기만 하고
코디네이터가 orca terminal read로 읽어 전한다.

물론 이 근거에도 빈틈이 있다.
코드 경로를 뒷받침하는 것은 에이전트의 서술 하나뿐이고 에이전트가
"의도된 안전장치"라고 단정한 말도 Orca 문서로 확인한 것이 아니다.
그래도 증상에서 출발해 앱 코드를 열고
반대 사례까지 맞춰 본 근거이므로, 같은 새벽에 내린 다른 결정보다 한 단계 위에 있다.

3분 만에 되돌린 절차

git worktree add 전면 적용은 시각 일치 하나에 기댔다.
전날 밤 Hindsight-Crew의 메인 체크아웃 HEAD가 다른 커밋으로 옮겨졌는데,
reflog에는 다음 줄이 남아 있다.

2026-10-02 04:13:05  pull -q --ff-only  (18e7593)
2026-10-02 23:22:26  reset: moving to 38e302c

코디네이터 워커는 보고에서 이 reset이
orca worktree create --base-branch origin/main
실행 시각과 겹친다며
그 명령의 부수효과로 추정했고 운영에는 영향이 없다고 봤다.
이튿날 새벽, 그 추정을 근거로 모든 리포의 워크트리 생성 절차가 바뀌었다.

바뀐 절차를 보고
"근데 이게나은거야? 문서보니까 오히려 절차가 더 길어졌네"라고 물었다.
에이전트는 명령이 1개에서 5개로 늘었고
얻는 이점은 메인 체크아웃 HEAD가 움직이지 않는다는 것 하나라고 답했다.
그 근거는 "reflog 시각이 1초 차이로 겹친 것을 보고 내린 추정"이고
재현해서 확인한 것이 아니라고 스스로 적었다.

3분 뒤의 커밋은 orca worktree create를 다시 기본으로 되돌렸다.
메인 체크아웃을 일부러 origin보다 뒤에 두고 운영에 쓰는 리포만 예외로 남겼고
Not-tested 줄에는 원인 재현이 시각 일치 추정뿐이라고 적었다.
지금 스킬 문서도 이 전례를 "재현 미확인"이라는 꼬리표와 함께 기록하고 있다.
추정은 추정이라는 표시를 단 채로 남았다.

확정이라 적은 hide 설정

hide가 원인이라는 판정은 한 런에서는 맞았고 다른 리포에서는 맞지 않았다.

커밋이 적은 것과 세션이 본 것

10월 3일 새벽, "show 해봐"라는 말에 에이전트는 그 워크트리에
orca worktree set으로 표시 이름과 이슈 번호를 붙였다.
결과는 ok: true였지만 리포의 워크트리 목록에는 메인 체크아웃 한 줄만 있었다.
에이전트는 이 메타데이터로 워크트리가 보이게 되는지는 확인하지 못했다고 답했다.
내 답은 "보인다 오케이 앞으로 이게기본"이었고
1분 뒤의 커밋은 메타데이터로 표시를 살린다고 적으며
"실측, BK 확인"을 달았다.
화면에서 실제로 무엇이 보였는지 알려 주는 근거는 그 한 마디가 전부다.

같은 값, 다른 결과

10월 14일 런은 원인 판정을 뒷받침하는 가장 강한 근거다.
경로 선택자로 약 8초 뒤에 다시 시도해도 실패하던 작업이
설정 하나를 바꾸자 성공했다.
스킬 문서는 이 런을 근거로
hide면 Orca가 워크트리를 인식하지 않는다고 쓰고
이 경로를 쓰는 리포는 show로 영구히 두라고 적는다.
그런데 10월 19일 vault 리포에서는 설정이 hide로 읽히는데도 첫 시도에 성공했다.
그 세션에서는 로컬 CLI로 show 변경을 세 번 시도했지만 설정을 바꾸지 못했다.

사실 selector_not_found라는 같은 문구 뒤에는 여러 원인이 있었다.
에이전트가 기억 기록을 바탕으로 구분한 원인은 세 가지다.
9월 26일부터 10월 1일까지는
Orca 1.4.217이 new-top-level 인자를 선택자로 읽었고
10월 6일 관찰되고 14일 확정된 원인은 hide 설정이었으며
show로 바꾼 뒤에도
git worktree add 직후 약 15초의 인식 지연이 있었다.
10월 6일의 "worker-start를 먼저 부르니 됐다"는 기록을
에이전트는 원인을 모르는 채로 순서를 바꿔 우회한 것으로 평가했다.

근거를 나란히 놓으면

결론

시각이 겹친다는 추정보다 코드를 열어 본 설명이 오래 버텼다.
다만 오래 버틴 쪽도 실행으로 재현한 근거는 아니었고
원인으로 확정했다고 적은 hide는 10월 14일 런에서는 맞았지만
10월 19일 vault 리포에서는 같은 값으로 다른 결과를 냈다.
화면은 보기만 한다는 규칙은 계속 지킨다.
다음에 할 일은 지금 설치된 Orca에서 화면 입력이 정말 행을 바꾸는지
한 번 실행해 보는 것이다.

한계·재검토 트리거

2026-10 기준 / 재검토 트리거: 지금 설치된 Orca에서
화면 입력이 워커 행을 user_owned로 바꾸는지 실행한 결과,
또는 hide 리포에서 orca worktree set 결과가 다시 갈리는 런

참고

• 검수·지휘 스킬 - super-auto 스킬 문서에 이 절차를 적은 경위
• 에이전트가 '완료'라고 적은 것들 - 기록과 실제가 어긋난 다른 사례
• Hindsight-Crew - 증상이 난 리포의 프로젝트