spawn-worker

name	spawn-worker
description	herdr로 워커/검증자 세션을 스폰(생성·기동·브리프 주입)할 때 반드시 사용. worktree 준비, 규모(T0~T3)·급(S+~C) 배정, 브리프 형식, 심각도 기반 검증 루프, 완료 보고 검증(ls-remote)까지 스폰 전 과정의 표준. 트리거 - "워커 띄워/스폰해", "검증자 붙여", "작업 시켜", wrk spawn·herdr agent start 사용 전.

spawn-worker — 워커 스폰 표준 절차

ROB-NNN 은 비공개 이슈 트래커 참조이며, 각 규칙 옆 본문이 근거를 자립 설명한다.

🔴 도메인 오버레이: $AGENT_SKILLS_DOMAIN/spawn-worker.md 가 존재하면 이 스킬을 적용하기 전에 반드시 먼저 읽어라. 없으면 아래 추상 규칙만 적용한다.

원칙: 워커의 자기보고는 증거가 아니다. 스폰의 완성은 기동이 아니라 "독립 검증 + 물증 대조(ls-remote)까지의 루프"다.

1. 작업장 준비 (스폰 전)

• worktree: 항상 최신 origin/main 기준. wt switch --create <이름> 우선(.env 자동 연결) — raw git worktree add는 .env 미복사라 DB/API 작업이 헛돈다(부득이하면 .env→.env.dev 심링크, prod 조회는 ENV_FILE=.env.prod 명시). canonical repo에서 직접 작업 금지(main 고정).
• 컨텍스트 버전 확인: 스폰 전 head AGENTS.md로 신판("얇은 포인터")인지 확인 — 구 브랜치 worktree는 stale 규칙이 로드된다. operator 레인 작업이면 cwd=해당 레인 디렉토리 (live/·mock/ — 레인 AGENTS.md가 최소 안전선).
• 스폰 이름: 이슈별 유일 이름(예: rob1234-fix). 범용명은 agent_name_taken으로 재사용 불가.

2. 배정 — 규모(T)와 급(S+~C)을 따로 정한다

두 축을 혼동하지 말 것. 규모 T = 검증을 얼마나 두껍게 할지, 급 = 어떤 모델을 쓸지다.

2-1. 규모 T — 되돌리기 비용으로 정한다

T	대상	검증 강도
T0	로컬 스크립트·설정, 30줄 이하, 되돌리기=파일 복사	스폰하지 않는다. 직접 처리 + 명령 1회 확인
T1	도구 레포(scopefuel·agent-skills 등), 런타임 무관	워커 1명, 자체검증. 적대검증자 없음
T2	auto_trader 비거래 경로	워커 + 적대검증 1라운드
T3	되돌릴 수 없는 외부 mutation·배포·안전가드	수렴형 풀코스(§5) — 여기서만

🔴 T3 판별 질문(기계적 판정 유지): 실패 시 사람이 외부 시스템에 개입해야 되돌아가는가? — 그렇다면 비가역 mutation 표면이고 T3다(예: 외부 시스템에 대한 되돌릴 수 없는 쓰기 요청 전송, 프로덕션 배포, 안전가드 변경 — 전부 "예"). git revert로 되돌릴 수 있으면 "아니다" → T3 floor 대상 아님.

• 브리프에 T를 명시한다. 명시가 없으면 수신측이 최대 강도로 해석해 과잉검증이 난다 (07-31 실측: 4과제 16라운드 → T 명시 후 평균 7분·0~1라운드).
• T1 상한은 브리프가 자족적일 때 유효하다. 명세가 얕으면 T를 올리거나 브리프를 보강한다.

surface-derived T floor (하향 거부): 상류의 T 제안(relay-handoff §1)과 무관하게, 변경 표면으로 최소 T를 기계적으로 계산하고 그 아래로는 내려갈 수 없다.

변경 표면	T floor
되돌릴 수 없는 외부 mutation·live·deploy·안전가드 경로	T3
auto_trader 비거래 경로	T2
도구 repo(scopefuel·agent-skills 등)	T1
로컬 스크립트·설정 ≤30줄	T0(floor 없음)

• 하향은 거부한다. 상류가 T1을 제안해도 표면이 비가역 mutation 이면 T3다(ROB-1189가 이 규칙으로 막혔을 사례). 상향은 자유(판단이 필요하면 올린다).

spawn_mode 자동 파생(빈칸 금지): T에서 자동으로 정하고 릴레이·브리프에 비워두지 않는다.

T	spawn_mode
T0	no-spawn(직접 처리)
T1	herdr worker 1명 + 자체검증
T2	herdr worker + 독립 verifier 1라운드
T3	herdr worker + 독립 verifier(다른 provider family 필수 — §2-4)

• 분류 불가 시 실행하지 않고 NEEDS_CLASSIFICATION으로 반환한다. 빈칸으로 두면 ROB-1196처럼 orch가 기본 도구(하네스 서브에이전트)로 처리해 §2-3 경계가 우회된다.

2-2. 급 — 작업 성질로 정하고, 후보는 도구에 묻는다

급	이런 작업	판별 질문
S+	되돌리기 어려운 판단, 설계 분기, 안전장치 설계	틀리면 되돌리는 비용이 큰가?
S	복잡한 구현, 새 추상화, 적대검증(급소 찾기)	무엇이 잘못될 수 있는지 스스로 열거해야 하나?
A+	일반 기능 구현, 기존 패턴 확장, 다단계 리팩터	방향은 정해졌고 설계 판단이 좀 남았나?
A	명세 확정 구현, 테스트 작성, 국소 수정	무엇을 만들지 문서에 다 적혀 있나?
B	기계적 변경, 리네이밍, 포맷, 문서 반영	정답이 유일하고 검색·치환에 가까운가?
C	단순 변환, 로그 파싱, 대량 생성	실패해도 버리고 다시 하면 되나?

급을 먼저 정하고, 그 급 안에서 쿼타로 고른다. 순서를 뒤집지 말 것 — 여유율만 보고 라우팅하면 최고 성능 모델이 계속 밀린다(07-31 실측: 벤치 4위 K3가 0회, 17위 모델이 5회).

scopefuel --recommend <S+|S|A+|A|B|C>   # 후보·순서·제외 사유·승급 후보를 한 번에

• 모델 목록·벤치 점수·풀 매핑을 이 문서에 적지 말 것. 정본은 scopefuel이다(레인이 추가·은퇴할 때마다 두 곳이 어긋난다 — 07-31 oc-*→clinepass 오매핑 사고의 원인).
• 승급 후보(⚠) 는 조건 충족 시에만 쓰고 근거를 이슈에 기록한다(예: fable은 Opus 5 대비 2배 가격 → 2h+ 자율·Opus 5 실패 후·고위험 1회성·서브에이전트 다수일 때만). 승급 후보는 인접 1급만 본다(ROB-1218) — C 작업에 S+/S 프로필을 "대안"으로 올리지 않는다.
• 비상 후보(정책 제외분)는 다른 후보가 전부 소진·측정불가일 때만, 역시 근거 기록.

🔴 effort 별 실사용 통계 조회 — launch_profile 이 정본 (ROB-1213 / ROB-1218)

quota_pool_records.profile 로 effort 별 실사용을 세지 마라. 그 컬럼은 게이트 정규화 이름이라 effort 변형을 뭉갠다(grok · grok-hi · grok-med → 전부 grok-hi). 정본은 events 의 quota_pool.record payload 안 launch_profile(모델@effort, ROB-1213). 2026-08-06 에 fable 이 낡은 컬럼으로 조회해 "grok medium 실사용 0건"으로 오판했고, 실제로는 grok@medium 1건이 돌고 있었다. 급 적합성·reps 집계·실사용 카운트는 항상 launch_profile (또는 scopefuel reps) 으로 확인한다.

2-3. 하네스 서브에이전트 vs herdr 워커 (경계)

오케스트레이터 CLI 는 자체 서브에이전트를 띄울 수 있다(codex ultra = max + 서브에이전트 병렬 등). 이것은 herdr 워커가 아니다 — 아래 규칙이 전부 우회된다:

	herdr 워커	하네스 서브에이전트
급 배정	scopefuel --recommend	❌ orch 와 동일 모델
쿼타	배정된 풀	❌ orch 자신의 풀
검증 독립성	다른 세션·다른 계열	❌ 같은 모델·같은 사각지대
관측	herdr agent list·인박스·PR	❌ orch 화면에만

• 서브에이전트 허용: 읽기전용 조사·카운트·검색 — 산출물이 orch 판단의 입력일 때. (예: "현재 main 에서 이 import 가 몇 개인가" 재검증)
• herdr 워커 필수: 코드 변경·테스트 실행·PR 생성 — 산출물이 검증 대상일 때. T2 이상은 예외 없이 herdr 워커.
• 비용도 워커가 유리하다 — 서브에이전트는 orch 쿼타를 몰아 쓰고, 병렬 모드는 토큰이 배로 든다. 풀 분산이 우리 구조의 목적이다.

근거(2026-08-01 ROB-1196): 릴레이에 T·급·스폰 방식이 비어 있자 orch 가 기본 도구(자기 서브에이전트)로 T3 급 실행 계약 코드를 구현·검증까지 처리했다. 검증이 BLOCKER 3건을 잡긴 했으나 구현·검증이 같은 모델이라 독립성은 없었고, codex 쿼타만 소모했다.

2-4. 불변식

• 검증 급 ≥ 구현 급. 같은 세션 자체검증은 무효(자기 확인).
• 쿼타를 이유로 급을 낮추지 말 것. 해당 급을 어느 풀에서도 못 뽑으면 스폰하지 말고 정지·보고한다.
• SPAWN_FORCE=1 우회 금지. 차단은 조치를 하라는 신호다(agy 계열이 측정 불가면 agy 세션 1개를 idle 쿼타 비컨으로 띄우는 것이 조치이지 force가 아니다).
• "스스로 검증하라" 지시 금지 → 시도 목록 열거 + 하한 명시(예: "테스트 X·Y 실행, 전수 grep 후에만 부재 단정").
• T3 verifier는 다른 provider family가 필수다(claude/openai/xai/moonshot 등) — 다른 모델명만으로는 부족하다(§2-3의 "다른 세션·다른 계열"을 T3에서는 '우선'이 아니라 '필수'로 올린 것). self-check(자체검증)는 제출 증거일 뿐 독립 검증으로 세지 않는다.

2-5. 미측정 프로필 실측(reps) 절차

급표의 추정치 프로필을 실측으로 전환하여 급 배정 정확도를 높인다.

1. 미측정 우선 배정: 해당 급에 추정 표기 프로필이 있고 그 풀에 쿼타 여유가 있으면 우선 배정을 고려한다. 특히 풀이 [WASTE] 리셋 전 소진 권장 이면 측정 비용이 사실상 0이다.
   • 🔴 T1·T2 가역 작업 한정: T3·비가역 mutation·배포·안전가드 표면에서는 절대 하지 마라. 미검증 프로필로 되돌리기 비싼 작업을 수행하는 것은 측정 이득보다 위험이 크다.
2. 브리프에 reps add 지시 포함: 작업 완료 후 워커 또는 orch가 실측 데이터를 기록하도록 지시한다.

   scopefuel reps add --profile <프로필> --model <모델> --task <이슈> --tier <T0|T1|T2|T3> \
     --role <impl|verify|fix|orch> [--effort <low|medium|high|xhigh|max>] [--grade <S+|S|A+|A|B|C>] \
     --rounds <재작업수> --blockers-found <수> --completed <0|1> \
     [--input-tokens <N>] [--output-tokens <N>] [--notes "<한 줄>"]
   

3. 🔴 정직성 규칙:
   • 토큰 수를 모르면 **생략하고 --notes 에 "토큰 미상"**이라 적는다. 추측 입력 금지.
   • 실패도 데이터다: completed=0 을 숨기지 마라. 라운드가 3번 돌았으면 rounds=3 이다. 좋아 보이려고 반올림하거나 축소 기록하는 순간 급표가 오염된다.
4. 재배치는 비자동: reps 데이터는 관측 근거일 뿐, 프로필의 급 이동은 운영자의 판단이다. 표본 1건 성공만으로 급을 즉시 올리지 마라(추정 프로필은 한 단계 보수적 적용 원칙 유지).
5. effort 별 통계 연동: effort 별 실사용 및 실측 데이터는 §2-2와 같이 events payload의 launch_profile 및 scopefuel reps 규칙(ROB-1218)을 상호 참조하여 집계·확인한다.

3. 브리프 작성 (자족적일 것)

포함: ①작업 정의+AC ②worktree 경로·브랜치 ③제약(하드 인바리언트 불변, 게이트 완화 금지, 직접 머지 금지 — 정지점=PR까지) ④완료 기준+보고 형식(실행한 테스트 원문, push SHA) ⑤금지사항 ⑥보고 채널=파일 인박스(orch에 send 금지 — 타이핑 충돌). 신규 job부터 ~/work/herdr-inbox/jobs/<job_id>/를 쓰고 job_id=<이슈>-<단계>-<YYYYMMDD-HHMM> 형식으로 정확한 보고 경로를 브리프에 명시한다(추측하게 두지 말 것). 기존 루트의 flat 파일은 이동·삭제하지 않는다 — 참조 경로가 메모리·문서에 남아 있다.

🔴 지시 ↔ 수용조건 1:1 (모든 브리프에 적용)

브리프의 각 실질 지시는 수용조건에 검증 가능한 항목으로 대응해야 한다. 대응이 없는 지시는 없는 것과 같다 — 산문으로 적혀 있어도 아무도 확인하지 않는다.

• 브리프를 다 쓴 뒤 역방향으로 훑어라: 지시 하나하나에 대응하는 수용조건이 있나. 없으면 둘 중 하나를 하라 — 체크 항목을 만들거나, 그 지시를 지워라.
• 수용조건은 관측 가능한 형태로 쓴다. "X를 반영할 것"이 아니라 "<명령> 출력에 X가 보이고 Y는 없음". 서술 요구("보고서에 적어라")는 체크가 아니다 — 보장이 없다.
• 🔴 작은 작업일수록 더 엄격히. 큰 작업은 수용조건을 촘촘히 쓰고 여러 명이 다시 보지만, 작은 작업은 성기게 쓰고 아무도 다시 안 본다. 검증 밀도가 작업 크기에 반비례하면 작은 일에서 샌다.
• 기계 검사로 바꿀 수 있으면 바꿔라 — 표 배치·경계·형식 같은 것은 테스트가 수용조건보다 낫다(사람이 매번 확인하지 않아도 회귀가 잡힌다).

근거 (2026-08-02 집계, 실패 5건 전수): luna medium을 B로 지시가 C에 들어감 / ROB-1189 급 오배정 / arbiter 뮤텍스로 파이프라인 90분 정지 / ROB-1196 서브에이전트 우회 / ROB-1150 비가역 외부 mutation 사고 4건. 5건 중 5건이 명세 단계 결함이고 실행 단계 결함은 0건이다 — 워커는 대체로 시킨 대로 했다. 특히 luna medium 건은 브리프에 산문 한 줄로 적혀 있었고 그 항목에 대한 수용조건이 0개였다. 같은 날 ROB-1202 는 수용조건 10개를 박아 10개 전부 독립 실측으로 통과했다. 차이는 워커가 아니라 명세였다.

🔴 프로덕션 e2e 입회 규칙 (2026-08-18 실사고 기반)

운영자 대상 실 알림 발송·프로덕션 기록 생성이 걸린 e2e 는 상류/운영자 입회 하에만 실행한다. 브리프에 환경을 명시하지 않으면 워커는 프로덕션에서 돈다 — 그게 가장 "진짜" 검증이기 때문이다.

• 해당 표면: 운영자 Telegram/알림 카드 발송 · 프로덕션 DB 행 생성(회고·제안·원장) · 외부에 보이는 상태 변경. 🔴 브로커 mutation 이 아니어도 사람에게 보이면 이 규칙이 적용된다.
• 브리프에 환경을 반드시 명시하라: test DB / dry-run / 프로덕션(입회 필요) 중 무엇인가. 명시가 없으면 그건 브리프 결함이지 워커 결함이 아니다.
• 프로덕션 e2e 가 정말 필요하면: ① 가드·불변을 먼저 뮤턴트로 증명 → ② 실행 전에 무엇이 어디로 가는지 고지 → ③ 실행 후 식별자(메시지 id·행 id·시각) 기록 → ④ 🔴 승인/실행 버튼은 누르지 않는다.
• 🔵 근거(2026-08-18 ROB-1285): AC 에 "e2e" 만 있고 환경 문언이 없어 워커가 머지 전에 프로덕션에서 실회고·실제안·운영자 실카드를 만들었다. 카드 자체는 승인 경로가 온전해 유효했지만(approved 0·주문 0), 머지 전 프로덕션 기록 생성은 경계 위반이었다.

비가역 mutation을 유발할 수 있는 브리프 3규칙 (ROB-1150 실사고 기반):

• 계약·레인 대조 = 브리프 1단계 게이트: 대상 자원을 레인 계약 문서· 레인 정책 이슈와 대조하는 판정을 브리프 첫 단계로 명시 ("충돌이면 실행 말고 회신"). 운영자 승인 릴레이도 그대로 옮기지 말 것 — 승인이 레인 계약 문서를 읽고 나온 게 아닐 수 있으므로 orch가 먼저 대조한 뒤 브리프화한다.
• 검증 지시는 방법까지 지정: "동작하는지 확인하라"는 워커가 mutation으로 실증하게 만든다(1왕복 승인이 2왕복 체결로). read-only 확인 방법을 지정하거나, mutation이 필요하면 범위를 수치로 못 박는다.
• 강도 보정(운영자 07-29): 이 게이트의 목적은 관료화가 아니라 "예약·봉인·read_only로 지정된 자원을 브리프가 뚫지 않는 것"이다. 봉인 캠페인·live·전용 예약 자원 = fail-closed 엄격 / 자유 mock 재량 범위 = 경량 확인(레인 계약 문서 1분 대조+충돌 시 보고)이면 족하다. 실수는 막지 못한 것을 보정하며 개선한다 — 절차를 무한히 두껍게 만들지 않는다.
• kiro 워커: "Linear는 읽기만, 이슈·코멘트 변경 금지" 필수(kiro Linear MCP는 write 가능).
• 무인 워커는 승인 우회 플래그 필요(codex --yolo, agy --dangerously-skip-permissions) — wrk spawn 프로필 매핑에 내장. mock 레인은 -L mock + MOCK_MCP_PROFILE 필수.
• 스폰 = Linear 기록 의무: 착수 시 이슈 등록/코멘트(이슈번호 명시). 태스크 상태는 세션 기억이 아니라 Linear가 정본 — 놓침 방지의 근간.

4. 기동·주입·감시

• 기동은 wrk spawn 우선(worktree+탭+기동+주입 원샷):

  wrk spawn -c <worktree> -m <프로필> -p <프롬프트파일> -w <워크스페이스> -l <라벨> \
            --t <T0..T3> --owner <내 세션 이름> [-L live|mock] [--effort <레벨>] [--job <id>]
  wrk --help          # 서브커맨드·옵션 전체
  

  신규 workspace 규약: workers(herdr workspace w16)는 worker/verifier 신규 세션에, orchs는 orch류 신규 상주 세션에 사용한다. 기존 세션은 이동하지 않으며, 이슈별 -w 값을 생략하거나 추측하지 않는다. -m 은 필수다(기본값 없음 — 오타가 조용히 Claude 워커를 띄우던 결함을 제거했다). 🔴 --owner <내 세션 이름> 을 항상 붙여라(ROB-1206). 이 값이 arbiter 의 owner_lane 으로 기록되어 나중에 §6 회수의 조회 키가 된다. 빠뜨리면 default 로 들어가고, 그러면 네 워커를 다시 찾을 수 없다 — 2026-08-02 에 기록 22건이 전부 default 라 어느 orch 도 자기 워커를 조회하지 못했고, 잔여 세션 11개를 운영자 세션이 손으로 걷어냈다. -L live|mock 은 실행 레인이고 --owner 는 스폰 주체다 — 축이 다르니 섞지 마라. 모르는 인자는 무시되지 않고 에러가 난다. 수동 기동은 herdr agent start <유일이름> --workspace <ws> --cwd <worktree> --no-focus -- <argv>.
• effort 는 인자로 준다 — 같은 모델도 effort 로 급이 바뀐다(실측: Luna Light 42 → Ultra 75). 프로필 이름에 effort 를 박지 말고 --effort 를 쓴다. 🔴 effort 별 실사용 건수는 quota_pool_records.profile 이 아니라 events payload 의 launch_profile 으로 센다(§2-2, ROB-1213). 정규화 컬럼은 effort 를 뭉갠다.
• ~/bin/herdr-spawn 은 wrk spawn 으로 위임하는 shim 이다(옛 경로 호환용, 신규 사용 금지).
• 브리프 주입과 제출 검증은 relay-handoff 스킬 절차를 따른다(제출 검증 생략 금지, 접수 확인 도구 1회 지시 포함).
• 감시는 agent_status 전이 기반(working→비working 2분 지속 시 확인). kiro/agy는 status 플랩(작업 중 idle/done 오표시) — 완료 판정은 상태가 아니라 산출물/화면 마커(PR URL· 최종보고·inbox 파일)로. 스폰 후 5분 내 실 툴호출 없으면 stuck 판정→재스폰.
• herdr 공식 시맨틱(0.8 번들 스킬, herdr --skill 이 정본): done = 미열람 idle (백그라운드 완료 후 아직 UI 에서 안 봄; CLI read 는 seen 처리 안 함) — done/idle 은 같은 비-working 상태다. 특정 문자열 대기는 sleep+read 루프 대신 herdr pane wait-output <pane> --match <텍스트> --timeout <ms> 를 써라(기존 출력에도 즉시 매치). 에이전트 이름/라벨은 [a-z][a-z0-9_-]{0,31} — wrk 가 스폰 전에 검증한다.

4-1. ACP headless 워커 경로 (acp-runner) — TUI 스폰의 대안

언제: T1 비거래·단발 구현/수정, 특히 비가역 mutation 표면이 없는 레포(도구·앱 레인). 구조화된 완료 신호가 필요하거나 herdr TUI 경로의 스크래핑 비용(주입 검증·상태 플랩·깨우기)을 피하고 싶을 때. 현재 에이전트는 junie 만(검증 완료 — JetBrains 쿼타, 모델 29종).

acp-runner --job <job_id> -c <worktree> -p brief.md   --model gemini-3.6-flash --timeout 1800
# 재작업 라운드: --resume <jobs/<id>/meta.json 의 sessionId>
# exit: 0=end_turn / 3=에이전트 오류 / 4=타임아웃 / 5=프로토콜

• 산출물: jobs/<id>/progress.log(실시간 스트림) · result.md · meta.json.
• pane 이 없다 — §6 회수 대상이 아니다(subprocess 가 완료와 함께 끝난다).
• 🔴 stopReason=end_turn 을 완료 증거로 쓰되 산출물 검증을 생략하지 마라. 2026-08-05 실측: resume 라운드가 4초 만에 end_turn 을 반환했는데 파일은 불변이었다 (ACP session/load 의 대화 재생을 새 작업으로 오인한 가짜 성공 — 러너가 드레인으로 고쳤지만, 신호와 산출물 대조 원칙은 프로토콜이 바뀌어도 유지된다).
• 🔴 게이트 밖이다: junie 는 scopefuel 미편입(JetBrains 쿼타 잔량 조회 경로 없음) — --recommend 로 뽑히지 않는 지정 배정이고, 비용은 junie 의 llmUsage(작업당 실비용) 로 기록·비교한다. 급은 미측정(harness=junie AA 미측정) — 보수 B급 취급, reps 로 측정.
• 무인 셸 실행이 가능하므로 worktree 격리 필수·비가역 mutation 표면 금지는 동일 적용.

4-2. 🔴 착지 검증 — 스폰 직후 필수

스폰 명령이 정상 반환됐다고 해서 워커가 브리프를 실제로 받은 것은 아니다. wrk는 herdr agent read <pane> --source recent-unwrapped --lines 200의 브리프 marker를 정본으로 확인한다(visible 화면에서 밀려나도 transcript에는 남는다). visible의 Pasted text 칩도 queued 양성 증거지만, working 단독은 콜드 부트 중에도 나오므로 착지 증거가 아니다. 일반 프로필은 30초, codex는 60초 창에서 0.5→2초로 backoff 관찰하고, 양성 증거가 없을 때만 최대 한 번 재주입한다. 자동화는 --landing-strict로 pane의 OK 행은 보존한 채 미착지를 exit 76으로 받을 수 있다.

wrk의 OK status=done도, herdr의 정상 JSON 응답도 둘 다 착지 증거가 아니다 — 콜드 스타트 실측 4회 중 3회 유실(자동 응답은 정상이었지만 실제 화면에는 브리프가 표시되지 않은 채 워커가 idle로 멈춰 있었다). 이 원칙("자동 보고는 증거가 아니다")은 wrk 자동화가 향후 착지를 보증하게 되더라도 별개로 유지할 가치가 있다 — 자동화 자체가 실패하거나 우회되는 경로는 항상 남는다.

5. 검증 루프 (스폰의 후반전)

강도는 §2-1의 T가 정한다. T0=스폰 없음 / T1=자체검증 / T2=적대검증 1라운드 / T3=아래 수렴형.

1. 워커 "완료" 보고 → git ls-remote로 push SHA 실재 대조(머지·배포·후속 스폰 전 필수).
2. 기계적 확인은 검증 라운드의 소재가 아니다. 테스트·lint·format·CI green·SHA 일치는 워커의 제출 전 체크리스트이고 증거(원문 출력)를 브리프에 첨부하게 한다. 검증자는 의미론·계약·실패모드에만 추론을 쓴다.
3. 적대검증자 스폰(T2·T3만): 새 세션(같은 worktree 가능·수정/커밋 금지), 입력=이슈 AC+PR+경로만. "틀렸다고 가정하고 반증": 독립 테스트 재실행, false-green 탐지(assert 뒤집기), AC 대조, merge-base 기준 스코프 확인. 템플릿=~/work/herdr-templates/VERIFY-TEMPLATE.txt.
4. 지적은 심각도를 붙여 보고하게 한다 — BLOCKER(동작 안 함·기존 기능 회귀·데이터 손상· 계약 위반) / SHOULD / NICE.
   • BLOCKER만 재작업 라운드를 트리거한다. SHOULD·NICE는 후속 이슈로 기록하고 머지를 막지 않는다.
   • 하드 캡 3라운드. 초과하면 코드가 아니라 설계가 불명확하다는 신호다 — 루프를 계속 돌리지 말고 운영자에게 에스컬레이션한다.
   • 심각도 하한이 없으면 적대검증자는 항상 무언가를 찾아내고 수렴이 무한히 늦어진다 (07-31 실측: 개선 제안 하나가 풀 라운드를 트리거해 4과제 16라운드).
5. 부재/미완 단정("테스트 없음"·"미배선")은 전수 탐색 후에만 보고에 인용.

6. 워커 회수 — 스폰한 주체가 거둔다

만든 곳이 회수한다. 워커가 언제 끝났는지, 그게 "끝"인지 "대기"인지 아는 것은 job 맥락을 가진 스폰 주체뿐이다. orch 뿐 아니라 직접 스폰한 어떤 세션에도 적용된다.

6-1. 트리거 — 깨어날 때마다 1회

orch 는 워커 완료를 자동으로 알지 못한다(2026-08-02 실측: 워커를 스폰한 뒤 1분 45초 만에 턴을 반환하고, 워커 둘이 도는 중에 done→idle 로 내려갔다. 폴링하지 않는다). 따라서 회수는 깨어난 순간에 확인해서 한다 — 새 릴레이를 받았을 때, terminal 을 선언할 때, 운영자가 깨웠을 때. 확인 비용은 몇 초이고 그때 너는 이미 깨어 있다.

arbiter status --lane <내 세션 이름> --json     # 내 job 목록 (세션 기억 아님)
# 각 job → jobs/<job_id>/events/*job.claim.json 의 agent_label
wrk find <agent_label>                          # → pane_id · status
herdr pane close <pane_id>                      # 회수

🔴 세션 기억으로 목록을 만들지 마라. compact 되면 사라진다. 정본은 arbiter + job 이벤트다.

6-2. 회수 조건 — 셋 다 만족할 때만

1. job 이 terminal — 머지·close·escalation 완료. 이건 네 판단이다.
2. 산출물이 파일로 확보 — jobs/<job_id>/ 에 최종 보고가 있다. 화면에만 있으면 닫는 순간 증거가 소실된다.
3. pane 이 비-working.

6-3. 🔴 비-working 은 회수 사유가 아니다

라운드가 끝났을 뿐 결정을 기다리는 중일 수 있다. 그 세션에 재주입할 예정이면 남겨라. 2026-08-02 실사례: uber-elig-worker 가 r3 에서 NEEDS_INFO 로 정지해 idle 이었는데, 운영자 결정이 나온 뒤 같은 세션에 재주입해 이어갔다. 컨텍스트가 자산이었다 — 그때 "idle 이니까 정리"했으면 처음부터 다시 올려야 했다.

6-4. pane close 만 쓴다

herdr tab close 는 쓰지 마라 — 같은 탭에 분할된 다른 pane 이 함께 죽는다 (2026-07-20 실사고: 수동 스폰한 캡틴 pane 동반 사망). pane close 는 그 pane 만 닫는다.

6-5. 죽은 탭 스윕 — agent list 로는 안 보인다

🔴 herdr agent list 는 살아 있는 에이전트만 보여준다. 스폰이 실패했거나 에이전트가 종료된 탭은 거기 없다 — 그래서 agent list 기준 정리는 죽은 탭을 영원히 못 걷는다 (2026-08-05 실측: w16 에 살아 있는 에이전트 7개, 실제 pane 18개 — 나머지 11개가 셸 프롬프트만 남은 죽은 탭이었고 스폰 재시도 잔해 krb0-v 만 3개였다).

스윕은 herdr pane list 에서 시작한다:

herdr pane list → 해당 workspace pane 전수
분류:
  ① 살아 있는 에이전트 pane (agent list 와 대조)     → §6-2/6-3 규칙대로
  ② terminal_title 이 셸 프롬프트(mgh3326@…)          → 죽은 탭. 닫는다
  ③ 그 외 (판별 불가)                                 → 화면을 읽고 판단

• ②를 닫아도 잃는 것은 종료된 에이전트의 스크롤백뿐이다 — 산출물 정본은 jobs/<id>/ 파일이다(§6-2 조건 2 가 이래서 선행한다).
• worktree 는 pane 과 별개다 — pane 을 닫아도 worktree 는 남는다(정리는 별도 판단).

(ROB-1214 로 wrk 가 스폰 실패 시 자기 pane 을 닫게 됐으므로 신규 누수는 줄지만, 비정상 종료·수동 스폰 잔해는 계속 생긴다 — 스윕은 여전히 필요하다.)

6-6. 백스톱

회수를 놓친 잔여는 계속 생긴다(세션 사망·compact·--owner 미지정 이력). 운영자 요청 시 스윕은 이 규칙과 별개로 유지한다 — 자동화가 아니라 이중화다.

실사례 근거 (2026-07)

• 워커 push 자기보고 허위 → ls-remote 대조 규약(#1640). 적대검증이 false-green 2건 적발(ROB-727).
• raw worktree add로 .env 누락 → DB 규명 워커 공회전 직전 적발(07-29).
• terra 조기정지 3회 → 체크포인트 계약으로 손실 0 격리. sonnet "green" 오보고 2회 → 전체 스위트 랜덤 순서로 적발.
• 07-31 과잉검증 실측: 심각도 하한·라운드 캡이 없어 4과제 16라운드(최장 2h34m). 브리프에 T1 상한(워커 1명·자체검증·BLOCKER만 재라운드)을 명시하자 평균 7분·0~1라운드로 수렴했고 수용조건 10건 전부 통과했다 → §2-1·§5.
• 07-31 매핑 드리프트: 쿼타 가드가 프로필→풀 매핑을 스킬·도구 양쪽에 중복 보유해 oc-*가 잘못된 풀을 조회(만차여도 초록불). 정본을 scopefuel 하나로 모아 해소 → §2-2.