🚨 [긴급·1순위] 멀티에이전트 통합 아키텍처 — 세부 상의 (cmdboard 자원 참조)

2026-05-29 KST · SARA(vscode_sara) 멀티에이전트 통합 설계 세부 상의. 채티↔사용자 대화 전체 기록. 긴급·1순위. 새 대화방은 이 페이지 + 인수인계서 최신 스냅샷을 읽고 이어받는다.

0. 한 줄 요지

vscode_sara는 cmdboard 파생물이고, cmdboard에는 이미 PLANNER/CODI/EVALUATOR/ROUTER 하네스 + 저장 모델(chat_messages·activity_logs·HandoffArtifact·continuation_state) + Phase 로드맵이 설계·일부 구현돼 있다. 따라서 SARA 멀티에이전트화는 백지 설계가 아니라 cmdboard 자원의 이식·재사용으로 접근한다. 두 목표(무할루시네이션 정확성 + 빠른 로드/저장)의 핵심 레버는 저장소 종류가 아니라 (A) 지식베이스 검색전략 + (B) 작업그래프 + 검증증거 기반 결과계약이다.

1. 논의 흐름 (시간순)

1. Obsidian 검토 — 노트앱 Obsidian(로컬 .md + git + AI 플러그인) vs 현재 Notion 아키텍처 비교. 결론: Obsidian은 .md+git 워크플로엔 맞지만 SARA 정확성·속도엔 레버가 아님. 트래커 DB·링크 공유는 Notion 우세. 하이브리드 가능하나 필수 아님.
2. Notion+RDS 캐시 평가 — 속도는 이미 RDS-first로 해결됨. 정확성 위험은 저장소가 아니라 캐시 전략: 현재 truncate(잘라담기) + 단일 페이지 크롤이 1순위 할루시네이션 원인.
3. 정확성↔속도 스펙트럼 — truncate-dump(현재, 위험) → full-dump(현 규모 최적) → 임베딩 RAG(규모 확장 시 정답, 근거 인용 가능).
4. 멀티에이전트 진입 시나리오 — 병목·할루시네이션 무게중심이 "읽기"에서 "지시·취합"으로 이동 → 두 레이어 분리 필요.

2. 핵심 결론 — 두 레이어 분리

• A. 지식베이스(파악용): 인계서·아키텍처·결정·코드. 읽기 위주, RAG. RDS 벡터 + Notion(작성/투영).
• B. 작업그래프(조율용): 플랜·태스크 상태·역할분담·결과. 읽기·쓰기 hot, 동시성. RDS 트랜잭션. (Notion=rate limit·블록 / Obsidian=git 충돌 → hot 조율 루프 부적합)

3. 할루시네이션 방어

• 지점 3개: ① SARA→지시(맥락 누락) ② 에이전트→작업(컨텍스트 부족) ③ 에이전트→결과보고(검증 없는 '완료').
• 최악 = ③의 연쇄 할루시네이션(SARA가 가짜 완료를 취합 → 전파).
• 차단법: 결과를 자유서술이 아니라 검증증거(테스트·커밋 해시·diff·py_compile) 기반 구조화 계약으로 회수 + 독립 검증층.

4. ★ cmdboard 자원 참조 (핵심 — 재사용 대상)

cmdboard V2(2026-05-25 확정) 허브·하네스 문서 기준, 다음이 이미 설계됨: - 역할 하네스: SARA(user-facing coordinator: 요청 수신·상태 요약·질문/승인·결과 보고) / PLANNER(=기존 채티: 작업계약서·완료기준·검증기준·CODI 지시문 작성) / CODI(코드 수정·테스트·커밋·보고) / EVALUATOR(독립 검증층: task_contract 기준 PASS/FAIL/수정요구, 직접 수정 금지) / ROUTER(다음 행동 결정·silent block 사유 기록·handoff 판단). - 저장/히스토리 모델: 사용자↔SARA=chat_messages / 내부진행=activity_logs / 장문 산출물=HandoffArtifact / 새 세션 이어받기=continuation_state. 카드 본문엔 최신 요약 + artifact pointer만(장문 누적 금지). - B 레이어를 새 테이블 없이: HandoffArtifact enum 확장 1회로 task_contract/evaluator_report/routing_decision/continuation_state 수용 가능(Phase 2 후보). - EVALUATOR 독립성 = 옵션 A 확정: 자가검증(저비용)을 baseline으로 → 독립 EVALUATOR는 위험 높은 작업에만 점진 도입(옵션 B 기각). - Phase 로드맵: P1 라벨 SARA화 → P2 PLANNER+task_contract → P3 EVALUATOR 독립 → P4 ROUTER decision → P5 continuation_state → P6 3-zone UI. (테스트 서버 :8003, 운영 master push 자동배포) - 참조 링크: cmdboard 허브 /3689512d9469810faa6dc5f90c0d0c38, V2 하네스 /36a9512d94698138aac4d6c3d5c306a2.

5. 매핑 — 이번 논의 ↔ cmdboard 기존 자원

SARA(부모 루프)
 ├① PLANNER → task_contract(JSON) → RDS
 ├② CODI(계약 전달) → 결과(JSON+.md) → RDS
 ├③ EVALUATOR(계약+결과 전달) → evaluator_report(PASS/FAIL/수정요구 + 사유 + 재현증거)
 └④ ROUTER(부모) 분기:
      PASS → 완료 처리 / FAIL·수정 → ②로 재호출(계약+required_fixes 주입) / 한계초과 → 사람 에스컬레이션

• EVALUATOR = 판정만(PASS/FAIL/수정요구), 직접 수정·재호출 금지(노션 §4 원칙 유지). CODI도 못 부름.
• 재진행 지시 = SARA(ROUTER 로직): evaluator_report.required_fixes를 원 계약과 합쳐 CODI 새 호출 프롬프트로 주입. 재호출은 신규 세션(기본·안전) 또는 resume(효율·오염위험) 선택.
• 완료 판단 = ROUTER→SARA: EVALUATOR PASS + 종료조건 충족 시.
• 검증 한계: outputFormat은 JSON 모양만 보장, 진위 아님 → EVALUATOR가 증거(커밋·py_compile·테스트)를 재실행 검증해야 ③ 차단.
• 품질 상한 = PLANNER 계약의 검증기준 구체성("동작하게" X → "잘못된 입력 테스트 통과" O).

8.5 무한루프·공모 방어

• 재시도 상한(예: 2~3회) FAIL → 자동중단+사람 에스컬레이션.
• EVALUATOR 독립성 = 옵션 A(저위험 자가검증, 고위험만 독립). CODI↔EVALUATOR 증거 공유하되 판정 분리.
• ROUTER가 차단·되돌림 사유를 activity_logs/routing_decision에 silent block 기록.

8.6 P1 권장 (단계 게이팅)

• P1 = 계획·검증 루프 자동화 먼저: PLANNER/EVALUATOR 서브에이전트 정의 + task_contract/evaluator_report JSON 스키마 + RDS 회수. CODI는 당분간 수동 유지(사람 디스패치=안전판).
• CODI 서브에이전트 자동화 = 별도 단계: ⓐ broker 경유 강제 + ⓑ EVALUATOR 통과 조건이 갖춰진 뒤 켬(인계서 미결 ⓑ bridge 방향과 일치).
• 미결 ① 갱신: 역할 4개를 서브에이전트로 이식하되 결과회수는 RDS task_contract로 구조화 강제, ROUTER는 부모 로직.
• 미결 ④ 갱신: 스키마(HandoffArtifact enum 확장)는 cmdboard와 공유, 서브에이전트 정의 파일은 SARA 리포 .claude/agents/ 자체 보유.

8.7 다음 산출물 후보

1. P1 작업계약서(.md): 서브에이전트 정의 범위 + 스키마 + RDS 회수 + 코디 게이팅 조건.
2. task_contract / evaluator_report / routing_decision JSON 스키마 초안.
3. 코디 서브에이전트 하네스 프롬프트 + outputFormat 스키마 샘플 1개.

8.8 병행 작업: RDS 메모리 MCP (이 대화방용)

• 목표: cmdboard RDS에 쌓인 SARA 메모리/핸드오프를 대화방 채티가 MCP 도구로 조회(읽기 우선).
• 진행: 별도 검토 중(읽기전용 MCP 서버 신규 vs 기존 notion-anchor류 패턴 재사용). 결정 시 본 섹션에 추가.

9. ✅ 완료 — 채티↔GPT 자동 소통 SW (agent-dialogue-hub 구축 완료, 2026-05-30)

사용자 지시로 새 1순위 = 채티(Claude)↔GPT 자동 협의 SW. 기존 멀티에이전트 통합(§1~8)은 2순위로 내림. 새 대화방은 이 §9 + 인수인계서 최신 스냅샷을 시드로 읽는다.

9.1 목표

채티와 GPT가 사용자 규칙 기준으로 자동(사람이 매 턴 개입하지 않고) 협의. 사용자는 상시 관전 + 선택적 개입(주입·일시정지·승인). 통신 기록은 RDS. 속도 우선.

9.2 핵심 제약 (리서치 확정)

• ChatGPT 데스크톱 앱은 로컬(localhost/http) 커넥터 거부("Unsafe URL"), 원격 HTTPS만. 게다가 사람이 입력한 턴에만 반응(자율 폴링 불가) → 앱으로는 자동화 불가능.
• 따라서 GPT 쪽은 OpenAI API 직접 구동이 유일한 자동화 경로. Plus 구독(앱)과 별개.
• Plus 앱 부가기능(누적 메모리·커스텀 인스트럭션)은 자동화 맥락에선 RDS(기록)+시스템 프롬프트(규칙)+허브 맥락주입으로 대체. 모델 지능 자체는 API로 동일.

9.3 확정 결정

• GPT 모델 = GPT-5.5 API ($5/M in, $30/M out, 캐시 $1.25). 세션당 대략 수센트~$0.5, 월 수달러~수십달러 추정. 비용 큰 레버=모델 선택(필요시 5.4로 하향).
• 채티 접속 = 로컬 stdio MCP(최속). GPT 접속 = OpenAI API.
• 둘 다 동일 로컬 대화 허브에 붙음. 터널 불필요(앱 안 씀) → 완전 로컬.

9.4 아키텍처

로컬 대화 허브 (FastAPI, 오케스트레이터=ROUTER)
  - 자동 핑퐁 루프: 턴 진행·종료조건(합의)·재시도 상한 N회
  - 규칙 강제: room/topic/role(chati|gpt)/kind(report|feedback) 스키마
  - 전 턴 cmdboard RDS 기록 (source of truth)
  - WebSocket 푸시
   ├ stdio MCP  → 채티(Claude)
   ├ OpenAI API → GPT-5.5 참여자
   └ WebSocket  → 웹뷰어(관전 + 선택적 개입: 주입/일시정지/승인)

• 사용자 관여 = 상시 가능·선택적(매 턴 강제 아님). 이게 "자동화" 요건.
• 멀티에이전트 설계와 호환: 허브=ROUTER, 전 턴=RDS 계약/기록.

9.5 재사용 자산

• cody-mcp-gateway(C:devtoolscody-mcp-gateway): 데스크톱↔Claude Code 로컬 MCP 브리지 + 위험도 분류 + broker 텔레그램 게이트. 허브 골격·게이트 로직 참고.
• sara-memory(2026-05-29 구현): RDS 읽기전용 조회 코어. 허브의 RDS 기록/조회 레이어 기반.
• SARA 웹뷰어 자산: 관전 UI 재사용.

9.6 미결 (새 방 결정)

1. 채티도 자동 루프에 넣을지: ⓐ채티도 Claude API/agent-sdk로 자동 구동(양쪽 대칭·진짜 자동) vs ⓑGPT만 자동, Claude는 SARA 패널 담당. (이 방 채티 앱은 GPT 앱과 동일 한계로 자동 루프 부적합)
2. 허브를 신규로 만들지 vs cody-mcp-gateway 확장.
3. 종료조건·재시도 상한·역할 프롬프트(사용자 규칙 주입) 구체값.
4. RDS 스키마: 신규 conversation 테이블 vs 기존 chat_messages 확장.
5. OpenAI API 키 발급·결제 셋업.

9.7 다음 산출물 후보

1. PoC 설계서(.md): 허브 스키마 + 메시지 버스 + 자동 루프 + 웹뷰어 + 규칙 강제.
2. RDS 대화 스키마 초안.
3. 허브 ↔ 채티(stdio) / 허브 ↔ GPT(API) 어댑터 PoC.

10. ✅ 합의 — 4미결 확정 (2026-05-30 KST, hub session #19)

§6 미결 1~4 전부 해소. 채티(PLANNER)↔GPT 자동 협의로 결론. (#19 원문 협의 결과 페이지는 삭제됨 — 결론은 아래 보존.) (다) CLI 러너 설계 후속 = 협의 결과 — (다) CLI 러너 설계 확정 (hub #28). 발행 전 선결 확인 5건 = §12(아래). 이 §10이 §1~9 설계의 실행 확정본이다.

결론

• ① 하네스 이식(미결1 해소): ROUTER(chat/task/verify_required 3분류) + EVALUATOR(task성 결과만 독립검증). 외부 /chat 응답 불변, 결과계약은 activity_logs/HandoffArtifact 내부 기록만(G11 회귀 차단). PLANNER/CODI = disabled adapter. ROUTER가 evidence 필수 대상 판정(task|verify_required만 EVALUATOR 게이트, chat 우회).
• ② 지식베이스(미결2 해소): full-dump 유지. RAG 전환 = 점유율(usage_ratio≥0.5 또는 첫턴≥0.65 빈발) AND 재현율(필수문서 누락 0건) 동시 충족 시만. 계측 cache_bytes/estimated_tokens/load_ms/usage_ratio.
• ③ 노션캐시(미결3 해소) — 최우선: truncate 제거 + 자식 전량 RDS 캐시(G2 큐 경유). 저장≠주입(주입 기본 summary). 자식 추적 = page_id 집합 diff + tombstone.
• ④ 공유 범위(미결4 해소): 스키마 cmdboard 단일소유(SARA DDL 0). contract 버전고정 vendoring. 하네스 vendored copy + upstream commit hash, 직접 import 금지.

실행순서 (확정)

③(저장 전문화+자식크롤, G2 큐) → ②계측 추가 → [차단해제: cmdboard 하네스 실파일 대조] → ①ROUTER+EVALUATOR 최소이식(task성만) → ②게이트 판정으로 RAG. ④는 전 구간 공유정책.

선행 차단조건 (코드 무변경, ① 전제)

cmdboard ROUTER/EVALUATOR/PLANNER/CODI 실파일 인터페이스·호출규약을 실제 대조(claude-agent-sdk 런타임 정합성). 미확인 상태로 ① 코드 착수 금지.

도구 상태

§9의 채티↔GPT 자동 협의 SW = agent-dialogue-hub로 구축 완료(:8780, PoC H1~H6 + A + B, 커밋 hub a49682d·SARA 82670c1). 본 합의도 그 hub로 도출.

11. ✅ 위임 실행 — 라이브 검증 결과 (2026-06-01, #23~#25)

§8(서브에이전트 실행 모델)의 실제 구현·검증 단계. SARA→코디(claude-code) 위임을 _bridge_e2e 브랜치에 구현하고 라이브 검증한 결과. 인수인계서 최신 스냅샷 #4와 동일 내용의 설계측 기록.

11.1 구현 (커밋 f470578, _bridge_e2e, master 미머지)

지시문 C:\dev\SARA\codi_bridge_delegation_fix_2026-06-01.md(GPT·채티 #23·#24 협의 반영). 5작업: 1. .claude/agents/codi.md — codi 서브에이전트 등록(§8.2 매핑 구현). tools = Read/Glob/Grep/Edit/MultiEdit/Write/Bash, Agent/Task 미보유(leaf 실행자=§8.1 1-depth 준수). 2. .claude/settings.json — 전역 broker 훅(PreToolUse→:7777) verbatim 복제(deny 27+hooks 3종). §8.3에서 예견한 "코디 서브에이전트 Bash의 broker 경유 강제 = P1 필수"의 구현 시도. 3. subagent_type=codi 강제 2층 — 계약 텍스트(render_contract_text) + 결합층(broker_gate Agent 분기 deny-on-mismatch). 4. diag 크래시 fix — extract_test_cmd 빈값 가드 + 검증블록 try/except + verify_error. 5. 단위 5케이스. pytest 115 passed(baseline 107+8), router_evaluator.py diff=0.

11.2 라이브 검증 (채티 오케스트레이션: 드레인→테스트기동 WS=C:devSARA·BRIDGE=1·loopback→PROBE→원복)

• ✅ §3 강제층 PASS — general-purpose 위임 시 broker_gate가 정확히 deny → SDK가 사유 반환 → 모델이 codi로 재호출(§8.4 ROUTER 분기의 deny→재시도 흐름이 의도대로 작동).
• ✅ §4 diag PASS — 크래시 0, verify_error:null 포함 완전한 diag 1회 발행.
• ❌ PROBE-0 (codi 인식) FAIL — codi로 재호출했으나 "Agent type 'codi' not found". codi.md는 위치·형식 정확하나 claude mcp serve 서브프로세스가 cwd의 .claude/agents/를 적재하지 않음.
• ⏸ PROBE-A/B·T2 = codi 인식 실패로 게이트 차단(설계대로 미실행).

11.3 ⛔ 근본 원인 + #25 재설계 과제

claude mcp serve는 도구 노출 서버라 프로젝트 .claude/agents/(서브에이전트)를 적재 안 함. §6 미결1("패널에 PLANNER/CODI 경로를 어떻게 들일지")의 핵심 기술 제약이 여기서 구체화됐다. §8.3에서 "broker 경유 강제"는 짚었으나, 그 전제인 "위임 대상 서브에이전트가 애초에 로드되는가"가 라이브에서 NO로 판명. - #25 시작점: (a) claude mcp serve --help로 --agents/--setting-sources/--mcp-config 등 .claude 적재 인자 실측 → (b) 없으면 SDK 위임 호출에 agents 옵션 직접 주입(ClaudeAgentOptions.agents) 검토 → (c) 그래도 안 되면 mcp serve 대신 SDK 인프로세스 서브에이전트로 전환. - fail-safe: SARA_CODI_BRIDGE 기본 OFF 유지(현행 단일 코디네이터와 동일). codi 인식 PASS 전까지 자동 위임 비활성. - 검증 재개 = PROBE-0 PASS → PROBE-A(broker 요청 실측, 0건이면 미게이트→자동쓰기 금지·에스컬레이트) → PROBE-B(force-push 더미 게이트, 실 push 0) → T2(실커밋·diag·verdict=pass) → master 머지(별도 승인). - [page] 협의 결과 — (다) CLI 러너 설계 확정 (hub #28, 2026-06-01)

12. ✅ (다) 발행 전 선결 확인 결과 — cmdboard 이식 시 깨지는 지점 5건 (2026-06-02)

hub #28 합의 §5("미확인 상태로 발행 금지")가 요구한 선결 확인을, 채티가 설치 CLI 실측(claude --version=2.1.154) + 공식 헤드리스 문서 + cmdboard 실코드 대조로 해소한 결과. (다) 코디 지시문(C:\dev\SARA\codi_cli_runner_2026-06-02.md)의 "발행 전 확인 결과" 표가 이 내용을 박은 것. 추후 (다) 구현이 사용자 의도와 어긋나거나 프로세스 작동에 문제가 생기면 이 절을 먼저 참조한다. 핵심 결론: cmdboard codi_runner_cli 패턴을 그대로 이식하면 깨진다. argv·권한·필드명 5개 지점에서 정정이 필요하고, 그 근거·조치를 아래에 보존한다.

12.0 검증 방법 (재현 가능)

• CLI 실측: claude --version → 2.1.154 (Claude Code). claude --help 전문 파싱(플래그·permission-mode·setting-sources).
• 공식 문서: code.claude.com/docs/en/headless (--bare와 hook/MCP/CLAUDE.md 로딩 관계).
• cmdboard 실코드: bridge/app/services/codi_runner_cli.py(argv 생성·_classify_failure), app/services/codi.py:671(apply_codi_result), app/api/tasks.py:9608(/codi/result-report payload 계약).

12.1 다섯 정정 (근거 → 조치)

A. --max-turns 플래그가 v2.1.154에 없다 (이식 시 즉시 CLI 에러). - 근거: claude --help의 max 계열은 --max-budget-usd 하나뿐. --max-turns는 목록에 없음. 그러나 cmdboard codi_runner_cli.py:1192는 "--max-turns", str(max_turns)를 argv에 그대로 넣음(+_classify_failure에 claude_cli_max_turns 분기 존재). - 조치: SARA argv에서 --max-turns 제거. 턴/비용 폭주 차단은 timeout_s(hard timeout) + 선택적 --max-budget-usd로 대체. claude_cli_max_turns 분류는 죽은 분기로 두되 전사 호환 위해 삭제하지 않음. - 영향: 이식 직후 모든 claude -p 실행이 unknown-option으로 실패하는 1순위 사고 지점. B. claude -p의 broker 훅 로딩 = --bare만 없으면 자동 (별도 인자 불필요). - 근거(공식 문서): --bare가 없으면 claude -p는 인터랙티브 세션과 동일한 컨텍스트(작업 디렉터리·~/.claude의 hooks·MCP·CLAUDE.md)를 로드한다. --bare를 붙이면 hooks/skills/plugins/MCP/auto-memory/CLAUDE.md 자동탐색을 전부 스킵하고 명시 인자만 적용. - 의미: §11(#25)에서 FAIL난 것은 claude mcp serve가 .claude/agents/를 안 읽은 것이고, claude -p는 그것과 다른 경로라 .claude/settings.json의 broker PreToolUse 훅이 기본 발화한다. (다) 채택의 핵심 근거(④번 이유)가 이 사실로 확인됨. - 조치: argv에 --bare 절대 금지. 훅 로딩을 명시적으로 못박기 위해 --setting-sources user,project,local 추가(유효 인자 확인됨). - 단, 실발화는 PROBE P-1·P-2 실측으로만 확정(broker 요청 0건이면 플립 영구 차단). 문서·코드 근거가 있어도 런타임 실측 전까지 자동쓰기 비활성. C. 위험 permission-mode = bypassPermissions인데 cmdboard 안전검사가 못 잡는다. - 근거: --permission-mode 유효값 = acceptEdits, auto, bypassPermissions, default, dontAsk, plan. 실위험값은 bypassPermissions. 그러나 cmdboard 안전검사(codi.py/codi_runner_cli.py:1165)는 if "dangerously" in permission_mode.lower()로만 막아 bypassPermissions 문자열을 통과시킨다. - 조치: SARA allowlist에서 bypassPermissions도 차단(들어오면 acceptEdits로 강제 치환). --dangerously-skip-permissions·--allow-dangerously-skip-permissions 플래그도 차단. 단위테스트 assert "bypassPermissions" not in argv_safe. D. cmdboard activity_logs.payload 정규 키 — commit_sha가 아니라 commit. - 근거: apply_codi_result(codi.py:671)와 /codi/result-report(tasks.py:9608) 두 entrypoint의 payload 정규 키 = result(completed/partial/failed), summary, commit(문자열), branch, tests(list[str]), changed_files(list[str]), notes, source(codi_stub/codi_runner/codi_user), error_code, chati_run_id, details_full/details_preview. (스키마 ④ = cmdboard 단일소유.) - 조치: SARA가 공유 RDS activity_logs에 직접 쓸 때 이 키 어휘를 그대로 재사용(필드명 드리프트 = ④ 위반). SARA 확장 ResultContract 전체는 sara_codi_cli_result 단일 키 1개에 중첩. source는 신규값 sara_codi_cli(기존값 충돌 금지). action명 codi_cli_result/sara_bridge_route/sara_bridge_task_verdict(cmdboard codi_done/codi_error/codi_result_reported와 비충돌). status→result 매핑: pass→completed, partial→partial, fail/timeout/stall/crash/blocked→failed. - 금지: apply_codi_result 등 cmdboard 함수 직접 호출 금지(Q1). SARA는 직접 SQLAlchemy로만 기록. E. --effort/--fallback-model 정확 표기 확정. - 근거: --effort <level> 유효값 = low, medium, high, xhigh, max(--reasoning-effort 아님). --fallback-model <model>은 정확 표기이며 --print 전용(=-p와만 동작). --model은 alias(sonnet/opus) 또는 full name(claude-opus-4-8) 허용. - 조치: argv 확장 인자 = --model / --effort(enum에 max 포함) / --fallback-model. (인수인계서 미커밋 드리프트 config/settings.json effort high→xhigh와도 정합 — 단 그 파일은 본 작업과 무관하므로 건드리지 않음.)

12.2 적용 결과 / 미확인

• 위 A~C·E는 이 머신의 설치 CLI(v2.1.154) 기준 실측이고, D는 cmdboard 실코드 기준. SARA는 이 머신에서 실행되므로 v2.1.154가 적용 버전.
• 미확인: cmdboard가 다른 머신/CLI 버전에서 구동되는 경우의 호환(SARA 작업 범위 밖). CLI가 업그레이드되어 플래그 셋이 바뀌면 A·C·E를 재확인해야 함.
• 후속: P-1·P-2·P-3 broker 실발화는 런타임 PROBE로만 확정(문서·코드 근거로 자동 활성화 금지).