martin1847/evolab

CTO Orchestration — 다중 에이전트 혼합 개발 오케스트레이션

핵심 철칙: 오케스트레이터 본인은 절대 제품 코드를 작성하지 않는다 — 아주 작은 변경도 실행 에이전트에게 맡긴다. 오케스트레이터의 산출물은 goal 문서, 모니터링, 리뷰 스케줄링, 의사결정, 상태 로그뿐이다. 출처: 다중 에이전트 CTO 실전 경험 (2026-06 부터).

제2 철칙: 실행 전에 검증하고, 불명확하면 먼저 묻는다. 되돌릴 수 없는/외부에 영향을 주는 동작 (push / merge / 배포 / 삭제 / 대외 메시지) 전에는 실제 사실과 현재 상태를 먼저 확인한다 (상태를 실제로 읽어라, 가정이나 도구의 단일 출력을 믿지 말라 — 로컬 ref는 속일 수 있다). 범위나 권한이 불분명하면 먼저 확인한 후 실행한다; 한 번 승인이 다른 동작으로 자동 연장되지 않는다. 되돌릴 수 있는 읽기 전용 동작은 즉시 수행하고 묻지 않는다. 실증: 사용자의 "push"를 "merge"가 포함된 것으로 착각하여 공유 브랜치에서 차단됨; 한때 git 병합 상태를 잘못 읽음 (단일 도구 출력에 모호함이 있어 cat-file -p로 실제로 읽어야 판명).

제3 철칙 (제2 철칙의 구체화): "주관자의 인지 부하를 낮추는 것"을 설계 목표로 삼는다 — 단일 의사결정 큐 (오케스트레이터 유지, 주관자 읽기 전용, 완전성 보장) + 3단계 위임 (T0 바로 실행 / T1 실행 후 한 줄 기록 / T2 실행 전에 질문) + 묵시적 기본값 (되돌릴 수 있으면 진행, 되돌릴 수 없으면 HOLD) + 배치 업그레이드 패키지 + 하트비트. 모든 것을 묻는 것이 아니라, "누가 결정할지"를 사전에 설계하여 주관자는 오직 무거운 결정만 내리고, 결코 기억할 필요가 없게 한다. §9 + references/decision-queue.md 참조.

0. 역할 분담 (능력에 따라 정의, 도구는 변경 가능)

방법론은 다음 능력에만 의존하며 특정 도구에 묶이지 않는다 (오케스트레이터 자신도 포함); 아래에 언급된 omp/codex/tmux ("너=Claude Code" 어조 포함)는 참조 구현이며, 스택을 교체할 경우 이를 기준으로 대체한다.

역할	하는 일 / 하지 않는 일	참조 구현 (변경 가능)
오케스트레이터 (너/CTO)	goal/증거 프롬프트 작성, 작업 할당, watcher 기동하여 최종 상태 판정, 리뷰 전달, 보고, memory/docs 저장, 작업 시스템 조작 + 정기/폴링 대비책; 제품 코드를 절대 작성하지 않음, 긴 E2E·대량 검증을 직접 실행하지 않음 (마무리 시 독립적으로 test+lint 다시 실행하는 것은 제외, §1.6 참조)	백엔드형(전달 최종 상태 읽기)/블로킹형(동기적으로 exit code 읽기); 모든 shell+파일 에이전트 가능, 세 가지 실제 실행 검증 (소비 경로 세부 사항은 references/agent-watch/README.md 참조)
실행 에이전트	goal을 받아 구현 + 자체 테스트 + E2E + findings; goal 범위를 초과하는 변경은 하지 않음. 상호작용 가능 (steering) + 바쁨 신호 + 생존 신호 필요	omp / Claude Code / aider…
리뷰 에이전트	읽기 전용 대항적 리뷰 (review), severity + verdict; 코드 변경/커밋 금지. 이종이어야 함 (실행 에이전트와 다른 계통)	codex / 다른 강력한 모델
운영 에이전트	접근 불가능한 환경(prod/독립 dev DB)에서 읽기 증거 수집 + 배포 후 검증; 수정/설정 변경 금지	사용자가 프롬프트 전달
전달 매체	명령어를 입력하고 화면을 캡처하여 출력하는 대화형 세션	tmux / 다른 멀티플렉서
watcher	"생존 + 바쁨 + 입력 대기"를 폴링하여 typed 상태 반환	references/agent-watch/ (dispatch/watch/teardown + hook; hook 주요 신호, 화면 캡처로 폴백)

기본값: omp 실행, codex 리뷰, 뒤집지 않음 — omp(oh-my-pi+Opus)는 자율 실행에 강하고, codex(gpt)는 엄격한 리뷰에 강하며, 교차 리뷰는 양쪽 모두가 놓친 실제 문제를 자주 잡아냄. 오케스트레이터 자신도 변경 가능 (codex/모든 shell+파일 에이전트가 CTO 역할 가능); §1.4의 watcher 기동 방식/바쁨·생존 신호는 사용자 도구에 맞게 조정하며, requires.bins의 tmux/omp/codex는 참조 스택이지 하드 의존성이 아님.

1. 작업 할당 프로토콜 (매번 전체 프로세스 수행)

1. 기준선 규율 (fetch+검사, 필요시 rebase, 통합은 squash 사용): 작업 할당 전 git fetch + 최신 원격 대상 브랜치 기준으로 worktree를 생성하며, 에이전트가 만료된 기준선에서 작업을 시작하지 못하게 함. 세 가지 판단 기준: ① rebase는 조건부 동작이지 의식이 아님 — base가 변경되지 않았으면 아무것도 하지 말고, 헛돌지 마라; ② 통합 기본은 squash, merge-commit은 폐기됨; ③ 읽기 전용 scout/audit/Explore가 Agent 도구를 통해 전송되면 묵시적으로 오케스트레이터의 cwd를 상속함 (뒤처진 메인 checkout) → 유령 발견으로 이어짐, 명시적으로 worktree를 지정하고 base ref에 대해 재확인해야 함. 전체 명령어 체인 / rebase 3분기 판단 / squash 설명 / scout 70-커밋 실증은 references/dispatch-baseline.md 참조; 권위 있는 git 세부 사항은 당신의 Git 협업 규범 참조 (evolab 공개 미러 git-workflow-standard 계획 중).
2. goal 작성 (템플릿 references/goal-template.md, docs/orchestration/<NAME>_GOAL.md에 저장): 컨텍스트+사전 연구 포함, file:line이 포함된 예측 ("verify, don't trust" 표시), 전달물, 검증 요구사항, 가드레일 (scope / stop-and-report / redaction / commit-local-no-push).
3. 전달 (dispatch 사용) + hook 검증 (하드 게이트) + 이해 게이트: references/agent-watch/dispatch를 사용하여 세션 시작, send-keys로 goal 경로 전달 (전체 명령어 체인 + 함정: text/Enter 배포, @ 자동 완성, codex 업데이트 프롬프트 — references/agent-watch/README.md 참조). 시작 후 즉시 hook 검증: watch가 걸리면 Read를 실행하고, 반드시 sentinel WORKING 줄이 보여야 함; no sentinel (hook not wired) → fallback = dispatch가 실행되지 않았거나 codex가 hook을 신뢰하지 않음 → 중단하고 다시 시작하고, 문제 있는 상태로 실행하지 마라. 전달 후, 작업 시작 전에 이해 게이트를 먼저 통과해야 함: 첫 번째 라운드에서 에이전트가 "어떤 파일/계약을 건드릴 것인지, 어떤 위험이 있는지"를 재진술하게 하고, 확인 후에 진행; 약한 답변/빗나감은 즉시 수정하고, 침묵을 묵인으로 간주하지 마라. 한 문장의 재진술로 "목표를 오해하고 무작정 수정"하는 대부분의 경우를 차단.
4. watcher 연결 (references/agent-watch/, hook 주요 신호, 화면 캡처로 폴백): 에이전트는 이미 step 3에서 dispatch로 시작되었으므로, 이 단계에서는 watch <session> 모니터링 + 마무리 teardown만 수행. 네 가지 판단 기준; 전체 매커니즘 + typed 상태 전체 열거 + STALLED-EXTERNAL / 비동기 완료 알림 블랙홀 / 양성 증거 두 가지 함정 / 폴백 자가 진단 / cto-guard 실증은 해당 디렉터리 README 참조:
   • typed 상태가 존재하고, DEAD≠DONE, WAITING은 입력을 기다리는 중 (idle / watcher 판정을 최종 상태로 착각하지 마라).
   • 완료 판단은 양성 증거에 기반해야 하며, idle / watcher 판정에 의존하지 마라 — tmux 링크에는 실패 신호가 없고, watcher 판정은 단지 단서일 뿐; 완료를 양성 전달물 (로컬 커밋/산출물 개수/리뷰 마커)과 연결하고, 직접 capture-pane으로 확인하라.
     • 분할 커밋 작업의 idle은 함정이다 (각 부분 경계에서 순간적으로 idle이 발생하며, 맨 idle/"첫 번째 커밋"은 중간에 오판할 수 있음; 실증: 3부분 리팩토링에서 Part A+C 후, Part B 전의 순간적 idle이 내 수동 폴링을 속임). 재발 방지는 구조에 의존하고 자율 규율에 의존하지 마라 (규칙만 기억하는 것은 소용없음 — 나도 규칙이 있었지만 위반함). 가드: references/agent-watch/cto-guard-bash.py 는 도구 호출 계층에서 "순수 idle-부재, 양성 grep 없음"의 맨 폴링을 DENY (git 전달물 검증 / pane에서 Verdict·prompt 캡처하여 진행).
   • 순수 이벤트 구동은 맹목적 대기로 이어짐 → 타임아웃 상한 설정으로 대비: 예상 시간 ×2로 폴백 자가 진단 설정 (ScheduleWakeup/cron), 시간이 되었는데도 최종 상태가 없으면 능동적으로 capture-pane 실행 — "WORKING 교착상태/열 재시도"의 절대 DONE 안 됨 해결 (위의 가짜 DONE과는 두 가지 실패 상태).
     • 브라우저/E2E subagent의 완료 알림은 블랙홀화됨 (살아있는 Playwright 세션/dev server/bg fork로 인해 알림이 트리거되지 않음 → 맹목적으로 죽을 때까지 대기). 전달 시 deadline 양성 증거 watch를 함께 배정하라 (출력 파일 증가/새 스크린샷/마일스톤 SendMessage 모니터링), 시간이 되어도 움직임이 없으면 SendMessage로 찌르고, kill+재시작하라, 자동 알림을 맹목적으로 기다리지 마라. 강제 계층: references/agent-watch/cto-guard-agent.py (PostToolUse·Agent|Task)는 전달 시점에 알림을 주입 (omission은 하드 deny할 수 없으며, launch 시에만 강제 salience; 알림은 JSON additionalContext를 통해서만 에이전트에 전달됨).
   • 백그라운드 시작 시 shell &를 절대 추가하지 마라 (이미 detached되었으므로, 추가하면 이중 백그라운드 = 고아 + 연결 끊김 오판); 실수에 대한 대비책은 PreToolUse·Bash의 references/agent-watch/cto-guard-bash.py를 통해 (뒤따르는 &/& disown 차단, 위의 idle-poller와 동일한 스크립트).
   • 와이어링: repo-governance-bootstrap §11에 이미 구축된 settings.json에 두 가지 hook 항목을 병렬로 추가 (세 가지 스케줄러 패턴을 그대로 사용, 별도의 스캐폴딩을 만들지 않음); CC frontmatter hooks:는 실제로 mid-session 활성화가 트리거되지 않으므로 의존하지 마라. 전체 테이블 + 두 항목은 references/agent-watch/README.md §Wiring 참조.
5. 스티어링: 새로운 사실/새로운 명령어가 나타나면, 보충 문서로 작성하거나 직접 send-keys로 세션에 전달하고, "당신의 가정과 모순될 때는 사실이 이긴다"라고 명확히 한다.
6. 마무리 검증 + Implemented→Verified: watcher는 idle을 측정하고, 에이전트는 "done"이라고 스스로 보고함 — 둘 다 Implemented일 뿐, 전달이 아님 (전달 상태를 실행자가 스스로 보고하게 하지 마라, §1.4 생존 감지는 동일한 주제). Verified로 승격은 오직 ①검증 4종 세트 통과 + ②이종 codex 독립 확인 시에만 가능 (실행자가 아무리 엄격하게 자체 검토해도 동일한 계통 = self-preference bias, 신뢰할 수 없음); roadmap / ACTIVE_CONTEXT / 티켓 종료는 오직 Verified만 인정. 검증 4종 세트 (git status / git log / test+lint 재실행 / grep 개수 + 실증)는 references/dispatch-baseline.md 참조.

2. 대항적 리뷰 사이클

먼저 위험에 따라 리뷰 깊이 결정: 낮은 위험은 경량 표준 리뷰 (codex review --base), 높은 위험 (인증/마이그레이션/인프라/대규모 리팩토링)은 전체 대항 사이클 진행. codex에는 내장 "대항" 모드가 없음 — 대항은 프롬프트 계층에서 수행 (자체 세션 시작, 축 포인팅 + severity/verdict + 다중 라운드 수렴), 반드시 자체 세션을 시작하고 자체 프롬프트를 제어해야 하며, 서브 명령어를 사용하지 마라. 전체 템플릿 + 축 전체 열거 + 실증 + ledger 컬럼 + 합격 기준선은 references/review-dispatch.md 참조. 판단 기준:

• brief는 냉 컨텍스트로, 자신의 결론을 끼워 넣지 마라 (codex에 내 판단을 먹이면 anchoring, 모델을 바꿨는데 추론 체인을 공유하면 상관 관계 제거 가치가 사라짐).
• 가장 실수하기 쉬운 축을 지목하라 (충돌 복구/동시성/플래그 관련 경로/성능 저하/보안 계약/멀티 테넌트 격리/메트릭 정직성), codex가 능동적으로 프로브를 작성하게 하라.
• 리뷰 전에 먼저 실행 경로 분기를 열거하라 (provider/mode, live vs rehydrate…), codex에 "아직 도달하지 않은 분기가 무엇인지" 확인하도록 지시.
• 게이트/트리거형 기능은 반드시 under-fire 검사 (해당 트리거가 실제로 트리거되었는지), over-fire만 검사하지 마라.
• 리뷰 기록은 ledger 구조를 사용하고, 단순 추가하지 마라 (blocking/queued/advisory/수정 완료/stagnation을 라운드별로 업데이트); 각 라운드 수정 시 원래 goal의 불변 검증 지점을 다시 붙여넣기.
• 세 가지 분류 수렴: blocking만 남아 있으면 계속 사이클; advisory→follow-up, 이미 준비된 push를 막지 마라; 이미 판정된 것을 다시 제기하지 마라.
• stagnation 감지: 동일한 finding이 반복적으로 나타나면 = 막혔으므로, 수렴하거나 인간의 개입을 요청하고, 무한 대응을 하지 마라.
• 리뷰 중에는 omp가 동일한 worktree를 건드리지 마라 (codex가 내부에서 테스트를 실행하면 결론을 오염시킬 수 있음).

3. 변경 규율

• 플래그 게이트: 동작 변경은 기본적으로 env flag 뒤에 숨기고, 기본값 OFF = 바이트 수준에서 0 변경; 예외: ReOpen이 승인한 수정은 기본값 ON 가능 (goal에 이유 명시). 성능/실험형은 전부 OFF.
• measure-before-more / 먼저 측정하고 판단: 첫 번째 조치 후 바인딩 제약 조건이 변경될 수 있음 — 먼저 실제로 측정한 후 두 번째 조치를 결정하고, 계산에 따라 여러 개의 레버를 연속으로 내리지 마라. 버그 수정도 동일, 작업 전에 검증 ① 버그 현재 상태에서 실제로 재현 가능한지, ② 관측값이 실제로 어떤 메커니즘에 의해 제약되는지 (관측값 5 < 상한 10 ⇒ 상한이 제약이 아님), ③ 실행이 실제로 당신이 의심하는 코드에 도달했는지 (코드를 읽어서 후보를 찾는 것뿐만 아니라, "실행이 여기까지 왔다"는 로그/trace로 증명). 바인딩 제약이 증명되지 않았으면, 계측 + 재테스트를 먼저 보내고, 투기적 수정을 보내지 마라 (실증: 코드를 세 라운드 읽고 전혀 존재하지 않는 "교착"을 추론, 매 라운드 실제 데이터에 의해 반박됨). 일반적인 가짜 버그: 잘못된 데이터 소스 조회 (빈 테이블을 실제 테이블로 착각 / 잘못된 로그 문자열 / 잘못된 세션), "받지 못함"(클라이언트) ≠ "보내지 않음"(서버).
• 커밋은 로컬에 유지, push/PR은 반드시 사용자의 명시적 승인 필요; 한 번 승인은 그 동작에만 적용됨.
• 검증 정직성: 전달 3단계 — 검증한 것 (실제로 실행함) / 검증하지 않은 것 / 남은 위험. 로컬에서 스텁 처리한 부분 (실제 LLM, 실제 큐)은 명시적으로 표시하고, 배포 후 운영에서 추가 검증. 실증: 로컬 LLM 스텁으로 인해 un-awaited 코루틴이 프로덕션으로 이스케이프됨.
• 대체 검증 경로 ≠ 실제 경로 (백엔드/에이전트/프론트엔드 공통): mock / 스텁 / stream smoke 전부 통과 ≠ 실제 경로 성립 — 실제 배포 경로로 검증하고, 대체 검증을 실제 검증으로 간주하지 마라. 실제 경로는 종종 당신이 mock한 그 경로와 다름 (프론트엔드 예시 §7: 카드는 execute/async를 사용하고 execute/stream이 아님, 3단계 통과에도 ReOpen). 가장 중요한 한 가지: 당신이 검증하려는 그 경계를 mock하지 마라 — 테스트 대상 함수를 스텁 처리 = 테스트 정보 제로, 정확히 버그를 덮음; 실제 애플리케이션 E2E만이 "테스트 가능" 문 (실증: 하루 안에 4개의 버그가 모두 리뷰+단위 테스트를 통과했지만, 오직 그것만 잡아냄).
• 편집 전에 변경될 파일을 다시 읽어라: rebase / 다른 에이전트가 동일한 worktree를 건드림 / 방금 파일을 변경하는 git 작업을 실행한 후에는, in-context 파일 뷰가 이미 오래됨 — 먼저 다시 읽고 수정하라. read-before-edit 보호 장치가 있는 도구는 stale 편집을 차단 ("must be read first" 오류는 버그가 아니라, 오래된 뷰로 다른 사람의 변경 사항을 덮어쓰는 것을 막는 것); 보호 장치가 없으면 조용히 덮어쓰므로 더 나쁨. 읽기와 편집 사이에 파일을 변경하는 명령어를 끼워 넣지 마라.

4. 간접 환경 접근 (운영 에이전트 모드)

접근 불가능한 환경 (prod, 독립 dev 런타임 라이브러리)은 추측하지 마라 — 자체 포함 증거 수집 프롬프트 (템플릿 references/ops-prompt-template.md, docs/orchestration/<NAME>_PROMPT.md에 저장)를 작성하여 사용자가 운영 에이전트에게 전달하게 하라. 핵심 사항 (읽기 전용 명령어만 / SQL을 완전히 제공 / 예상 판독값+판단 규칙을 완전히 제공 / 보고서 형식을 고정 / 민감 데이터는 메타데이터만 수집)은 해당 템플릿 참조. 판단 기준: 운영 보고서의 우선순위가 자신의 추론보다 높다 — 현장과 HEAD 코드가 모순될 때, 먼저 빌드 드리프트 (구 버전이 배포됨)를 의심하고, 그 다음에 자신의 제어 흐름 분석을 의심하라.

5. 상태 로깅 및 리듬

• docs/orchestration/ 가 SoT: *_GOAL / *_FINDINGS|IMPL_omp / *_REVIEW_codex / *_PROMPT / *_RESULT, 이름에 작업 번호가 포함되고 모든 file:line 증거 포함. 수명 주기: 종료 시 문서를 archive/로 이동 (README에 인덱스 라인 추가), live에는 실행 중/대기 중인 것만 남김; 문서는 생성만 되고 삭제되지 않음 → live와 기록이 혼합됨 (실증: 어떤 프로젝트는 38개가 쌓인 후에야 처음 정리).
• memory: 각 workstream마다 하나의 파일 + 인덱스 한 줄 (상태/PR/노출/다음 단계 진입점), "압축/외부 입력 대기" 전에 반드시 업데이트. memory는 오케스트레이터 전용이며, 에이전트/새 세션은 docs만 읽을 수 있음 — memory만 업데이트하고 docs를 동기화하지 않으면 공유 거버넌스 계층이 썩음 (실증: 어떤 프로젝트 ACTIVE_CONTEXT가 4일 동안 얼어붙어 휴지통이 됨). 3분담: docs는 모든 에이전트가 공유하는 상태 스냅샷 (what/why)을 저장하고, ACCESS.local.md는 연결 방법 + 자격 증명 (how-to-reach, 민감 정보는 gitignored, repo-governance-bootstrap 참조)을 저장하며, memory는 오케스트레이터 전용의 교훈 + 진입점 포인터를 저장. 단기 working 기억 (현재 작업 초안/진행 상황/할 일)은 이 세 가지에 포함되지 않음 — context window 또는 임시 /tmp NOTES에 살며, 쉽게 버릴 수 있으며, memory (크로스 세션 전용 계층 오염) 또는 ACTIVE_CONTEXT (종료 스냅샷이지 초안이 아님)에 넣지 마라.
  • 기록 규율 (복습을 기다리지 않음): 위의 오프로딩은 작성하면서 수행 — memory를 작성할 때 현재 사실 세부 사항을 ACCESS/docs에 바로 넣고, 복습할 때까지 쌓아두지 마라. skill 텍스트만으로 기억하기 어려운 고빈도 규율에는 PostToolUse hook 대비책 사용 (강제 계층이 salience 감소를 보완; 템플릿은 repo-governance-bootstrap 참조).
• 복습 의식 (이벤트 트리거: 종료 / 압축 전 / 모든 ReOpen 후 능동 제안) — CHECKLIST이지 즉흥이 아님. "복습 / 종료 / handoff"을 들으면 → references/retrospective.md 7단계를 항목별로 읽고 따르라, 기억에 의존하여 즉흥적으로 하지 마라 (즉흥 버전은 완전해 보이지만 중요한 거버넌스 단계를 조용히 누락함 — 실증 2026-06-26: "복습 의식"을 요청받았지만 자유롭게 수행하여, roadmap 상태 업데이트 + ACTIVE_CONTEXT 전체 다시 쓰기 + 컨텍스트 거버넌스 누락).
  • 하드 게이트 (통과하지 않으면 완료 선언 불가): bash references/retro-check.sh --base <branch> --docs <docs-dir> --memory <MEMORY.md>를 실행하여 기계적 검증 수행 (병합된 브랜치에 고아 worktree 없음 / ACTIVE_CONTEXT 오늘 다시 작성됨 / roadmap 최근 변경 / MEMORY 줄 수 초과 안 됨); 기계적 대리만 검증하고, 의미론은 당신이 결정.
• 고아 정리: 전달 완료된 세션 종료 (중요한 컨텍스트를 보유하고 일시 중단된 것은 유지); 에이전트가 생성한 고아 정리 — docker ps / ps / 백그라운드 job. 임시 compose는 trap/finally down --remove-orphans 사용, repro는 맨 while True 금지 (유계 루프/deadline 사용). 실증: 어떤 repro 무한 루프가 2.5일 동안 공회전, CPU 65%.

6. 작업 시스템 (외부 작업 추적: Jira / Linear / Feishu bitable 등)

• 작업 시스템의 CLI / API를 사용하여 작업 읽기/쓰기; 상태 머신은 프로젝트에 따라 정의됨 (처리 대기/처리 중/테스트 가능/완료/차단/ReOpen).
• 티켓 종료 기준: 수정 → E2E 검증 → 스크린샷 증거를 작업 첨부 파일에 업로드 (검증자가 한눈에 비교) → 한 줄 결론 → 상태 변경.
• ReOpen: 먼저 증거를 수집한 후 수정 — 이전 라운드의 "수정 완료" 메커니즘이 실제로 바인딩 제약이 아닐 수 있음.
• 거버넌스 문서에 두 번째 작업 장부를 만들지 마라: 외부 시스템이 작업 SoT이며, roadmap은 단지 매핑 계층일 뿐. 규칙 세부 사항 (외부 ID 유지 / SoT 명시 / 언제 내부 RD 번호를 생성할지)은 repo-governance-bootstrap의 "외부 작업 시스템 우선"에 의해 구현됨.

7. 프론트엔드 수정 검증 (브라우저 디버깅)

프론트엔드 작업 할당 후, 검증 규율: 코드 리뷰 + 단위 테스트만으로는 충분하지 않으며, 반드시 브라우저로 돌아가 실제 렌더링을 확인해야 함; mock / SSE 프레임 / 로컬 모두 통과 ≠ 실제 사용자가 볼 수 있음 — 종료는 배포된 실제 애플리케이션에 로그인하여 실제 라운드를 실행하고 스크린샷을 찍어야만 인정됨 (대체 검증 경로≠실제 경로의 프론트엔드 예시, 일반 원칙은 §3 참조). E2E는 검증이며, 오케스트레이터의 메인 컨텍스트를 차지하지 않음 — 브라우저 MCP가 있는 서브 에이전트에게 위임 (§0 "긴 E2E를 직접 실행하지 않음"의 프론트엔드 예시). 완전한 방법론 (MCP 메인 CLI 보완, a11y 우선, 네트워크 패널로 네트워크 버그 진단, CLI로 SSE 캡처, 전달 종료, E2E를 서브 에이전트에게 위임, 로컬 서비스 시작 함정을 프로젝트 AGENTS.md에 포함)은 references/frontend-verify.md 참조.

8. 새 프로젝트 온보딩 체크리스트

새 프로젝트 온보딩 6단계 (부트스트랩 거버넌스 스켈레톤 → 위임 경계 보완 → orchestration 디렉토리 생성 → 첫 작업을 §1 전체 프로세스로 진행 → memory working-style 항목 생성 → DECISION_QUEUE 생성)는 references/onboarding-checklist.md 참조.

9. 주관자 집중력 및 의사결정 큐 (인지 부하 감소)

제3 철칙의 구현. 목표는 주관자가 적게 결정하는 것이 아니라, 오직 무거운 것만 결정하게 하는 것 (전략적/되돌릴 수 없음/돈/가치), 각각에 대해 씹힌 옵션을 제공하고, 절대 기억할 필요가 없게 하는 것. 완전한 방법론 (7가지 메커니즘 + 위임 보드 + 실패 모드 + 출처 정직 표기 + copy-paste 템플릿)은 references/decision-queue.md 참조. 이 섹션에는 중요한 요점만 남김:

• 단일 의사결정 큐 docs/DECISION_QUEUE.md: 오케스트레이터가 유지, 주관자 읽기 전용. 🔴그의 결정 필요/🟡내가 주도/💤일시 중지/✅처리 완료. 완전성 보장=유일한 면, 다른 곳에 저장하지 않음, 조용히 잃지 않음 (신뢰 전제, 그렇지 않으면 오프로드 실패). 각 🔴에는 권장 + 묵시적 기본값 + revisit 트리거 포함.
• 3단계 위임: T0 직접 실행 (되돌릴 수 있음/이미 승인됨/가치 판단 없음) · T1 실행 후 한 줄 기록 (되돌릴 수 있지만 알림이 필요하고 거부 가능) · T2 실행 전에 질문 (되돌릴 수 없음/대외적, 전략/우선순위/돈/가치, 실질적인 하향이 있는 진정한 모호함). 부하 감소 = 많이 T1으로 이동하고, T2를 동기 게이트로 적게 사용.
• 묵시적 기본값: 주관자가 응답하지 않음 → 되돌릴 수 있으면 명시된 기본값대로 진행, 되돌릴 수 없으면 전부 HOLD (절대 자동으로 되돌릴 수 없는 것을 넘어가지 마라).
• 나머지 메커니즘 (집계 트립 와이어 / 배치 업그레이드 패키지 / 하트비트 / HELD revisit / 큐 부패 대비 / 세 가지 계층 거버넌스 혼동 금지)은 references/decision-queue.md 참조.