CMDBOARD V2 — SARA 대화 구조와 PLANNER/CODI/EVALUATOR/ROUTER 하네스 확정

목적

이 페이지는 2026-05-25 확정된 CMDBOARD V2 역할명·대화 구조·하네스 보완 방향을 기록한다. V2는 CMDBOARD 전면 재개발이 아니다. 기존 CMDBOARD를 유지하면서 SARA 사용자 대화 구조와 PLANNER/CODI/EVALUATOR/ROUTER 내부 하네스를 점진적으로 보완한다.

핵심 결정

전역 SARA 대화방은 전체 카드 관리와 비서 역할로 유지한다.
카드 상세별 기존 채티 대화방은 없애지 않는다.
카드 상세별 기존 채티 대화방은 해당 카드 작업 담당 SARA 대화방으로 표시명과 개념을 전환한다.
사용자는 PLANNER/CODI/EVALUATOR/ROUTER와 직접 대화하지 않는다.
사용자는 전역에서는 전체 비서 SARA와 대화하고, 카드 상세에서는 해당 카드 작업 담당 SARA와 대화한다.
실제 내부 작업은 PLANNER/CODI/EVALUATOR/ROUTER가 분담한다.

대화방 구조

전역 SARA 대화방
= 기존 사라 전용 대화창
= 전체 카드 관리 / 전체 현황 요약 / 비서 역할

카드 상세별 SARA 대화방
= 기존 카드 상세 안 “채티와 대화” 영역
= 표시명과 개념만 채티 → SARA로 변경
= 특정 카드 하나의 작업 진행 대화 상대

내부 하네스 역할

역할	의미	책임
SARA	사용자-facing coordinator	사용자 요청 수신, 상태 요약, 질문/승인 요청, 결과 보고
PLANNER	기존 채티의 새 역할명	작업 계약서, 완료 기준, 검증 기준, CODI 지시문 작성
CODI	기존 코디	실제 코드 수정, 테스트, 커밋, 결과 보고
EVALUATOR	독립 검증층	CODI 결과를 task_contract 기준으로 평가. 직접 수정 금지
ROUTER	흐름 결정 담당	다음 행동 결정, silent block 사유 기록, handoff 판단
## 중요한 정정
EVALUATOR는 자기 작업을 평가하는 agent가 아니다. EVALUATOR는 CODI 결과를 독립 검증하는 검증층이다. 직접 코드를 수정하지 않고, PASS/FAIL/수정 요구를 작성한다.
## 저장/히스토리 원칙
- 사용자 ↔ SARA 대화는 chat_messages에 남긴다.
- 내부 진행은 activity_logs에 남긴다.
- 장문 산출물은 HandoffArtifact에 남긴다.
- 새 세션 이어받기는 continuation_state로 처리한다.
- 카드 본문에 장문 히스토리를 계속 누적하지 않는다.
- 카드에는 최신 요약과 artifact pointer만 둔다.
## 개발 방식
첫 작업은 대규모 코드 수정이 아니라 Phase 0 감사다.
CODI에게 전달할 1차 작업:

CMDBOARD V2 Phase 0/1: 대화 구조·역할명 감사 및 첫 패치 계획

필수 산출물:

docs/cmdboard_v2_phase0_audit.md
docs/cmdboard_v2_naming_map.md
docs/cmdboard_v2_first_patch_plan.md

금지 사항

전역 SARA 대화방과 카드 상세 대화방 통합 금지
기존 chati API/DB enum 즉시 삭제 금지
전체 재개발 금지
supervisor/critic 전면 삭제 금지
운영 배포 금지
EVALUATOR가 직접 코드 수정하는 구조 금지

Phase 0 감사 결과 (2026-05-25, CODI 보고 수신)

산출물 3종 생성: docs/cmdboard_v2_phase0_audit.md / cmdboard_v2_naming_map.md / cmdboard_v2_first_patch_plan.md. - 사이드 채팅 패널(_chat_pane.html)은 이미 SARA 명칭 → 변경 불필요. - Phase 1 실제 대상 = 단 2개 파일·약 9~11라인 라벨 교체: chati_chat_integration.js(라벨 9건) + app.js:4771/4802(라벨 2건). - DB / API / Bridge 무변경. chati enum·/api/.../chati/messages URL 유지, UI에서만 SARA alias. - supervisor/critic 8 actions = ROUTER+EVALUATOR 전신, Phase 1 미접촉. - HandoffArtifact는 enum 확장 1회로 task_contract/evaluator_report/routing_decision/continuation_state 수용 가능(Phase 2 후보).

OPUS 판단 확정 (Phase 1 범위)

Phase 1 = DB migration 없이 라벨만 교체. 내부 chati enum/API/queue 유지, 문서상 chati=PLANNER alias.
task_contract는 Phase 2(HandoffArtifact 재사용·새 테이블 없음). EVALUATOR 초기 전건 실행. ROUTER는 Phase 4 routing_decision 분리(기존 NEXT에 alias부터).

다음 시작점 (Phase 1 진행)

코디에게 Phase 1 라벨 교체 지시문 전달(2파일·9~11라인, :8003 한정)
:8003 적용 → 12종 회귀 검증(전역 SARA / 카드 SARA / 자동순환 API / CODI 흐름 / activity_log 500 없음 / 모바일 등)
검증 PASS → 운영 배포 결정
Phase 2 = artifact enum 확장 → EVALUATOR 분리 → ROUTER 통합 순

최종 목표 문장

전역 SARA 대화방은 전체 비서 역할로 유지하고, 카드 상세별 기존 채티 대화방은 해당 카드 작업 담당 SARA 대화방으로 이름과 개념만 전환한다. 실제 내부 작업은 PLANNER / CODI / EVALUATOR / ROUTER가 수행한다.

트랙 매핑 — V2 Phase ↔ 기존 묶음 통합안 (2026-05-25 정리)

두 트랙은 별개 작업이 아니라 같은 리팩터를 다른 어휘로 서술한 것이다. - 기존 묶음(통합안)은 실제 코드 의존성을 담은 실행 엔진이다 (supervisor · NEXT · enum · 토글 · 게이트). - V2 Phase는 그 위에 입히는 역할 어휘 · 사용자 구조다 (PLANNER/CODI/EVALUATOR/ROUTER, SARA 대화 구조). - 따라서 시행 순서는 묶음 의존성을 따르고 V2 역할명을 병기한다. 두 계획을 병렬로 돌리지 않는다. | V2 Phase | V2 의미 | 대응 묶음 / 코드 | 관계 | | --- | --- | --- | --- | | Phase 1 | 카드상세 라벨 채티→SARA | 라벨만 선분리 (묶음2.5와 별개) | V2 신규, 즉시 | | Phase 2 | PLANNER + task_contract | 묶음1.5(GENERAL_CHAT_PROMPT 4기준) + D1 흡수 | 채티=PLANNER 확정, 완료기준 내재화 | | Phase 3 | EVALUATOR 독립 검증 | 묶음3(D1 물리 삭제) 직후 분기 | ★결정 대기 (아래) | | Phase 4 | ROUTER decision | D3 8종 NEXT 매핑(D3-a/b/c) + 묶음5 | NEXT/next_mode = ROUTER 전신, alias부터 | | Phase 5 | continuation_state | 묶음4(D3-b) + chain rollup + 토큰 공통기록 | HandoffArtifact · chain_id 위에 | | Phase 6 | 3-zone UI | 묶음2.5(3-zone + 게이트 진단 zone) | 동일 작업 |

★ 핵심 결정 확정 (2026-05-25) — EVALUATOR 독립성: 옥션 A

충돌: D1은 critic 4기준(commit/exit/summary/goal)을 채티(PLANNER) 프롬프트로 흡수(자가검증, 저비용). V2 Phase 3은 EVALUATOR를 독립층으로 원함(별도 검증, 고비용·고견고).
그대로 두면 critic 로직을 채티로 넣었다가(D1) 다시 빼는(Phase 3) 낭비가 생길 수 있음.
옵션 A (권장): D1 흡수를 baseline으로 완성(묶음1 조건부 통과·read-only hold 정확분류 검증됨) → 독립 EVALUATOR는 Phase 3에서 위험도 높은 카드에만 점진 도입.
옵션 B: D1 흡수 건너뛰고 처음부터 별도 EVALUATOR 호출 → 비용↑, 묶음1/1.5 재작업.
결정: 옥션 A 확정 (2026-05-25). D1 흡수를 baseline으로 완성 → 독립 EVALUATOR는 Phase 3에서 위험도 높은 카드에만 점진 도입. (옥션 B 기각)

통합 시행 순서 (묶음 의존성 기준 · V2 역할명 병기)

Phase 1 — 카드상세 라벨 SARA화 [:8003] (독립, 즉시)
묶음1.5 — GENERAL_CHAT_PROMPT 4기준 보정 → 묶음1 종결 [= PLANNER 흡수 착수]
묶음2(D2) + autorun_blocked_reason 로그 표준화 [= 개입 토글]
묶음2.5 프론트 3-zone + 게이트 진단 zone [= V2 Phase 6 UI]
토큰 공통 기록 [= Phase 5 전제]
묶음3(D1 물리 삭제) → ★EVALUATOR 독립 분리 결정 (Phase 3)
chain rollup + per-chain cap [= Phase 5 전제]
묶음4(D3-b: resume·핸드오프) [= Phase 5 continuation_state]
묶음5(D3-c: 재라우팅·abort) [= Phase 4 ROUTER terminal] → 운영 Tier2 배포
Job1 재검토