변경 이력

대화 중 결정/변경이 발생하면 즉시 추가한다.

[2026-05-14] BigBoss OS 공식 웹사이트 구축 완료 (`site/`)

Why: 오픈소스 GitHub 스타 목표 + bigbossos.com(Cloudflare) 도메인 보유했으나 공식 웹사이트 부재. dashboard/(운영 콘솔)와 별개의 대외 홍보+문서 사이트 필요.

회장 결정: 신규 site/ 폴더 / 순수 HTML+CSS+TypeScript(프레임워크 금지) / npm 런타임 의존성 0(직접 작성 마크다운 변환기) / Cloudflare Pages 배포 / 마피아·조직 테마 / 랜딩+문서+changelog+roadmap / 공개 문서는 Claude 선별 / 랜딩 KO+EN 토글.

What (Phase 1~3 완료):

Phase 1 — 스캐폴드(package.json/tsconfig.json, devDep: typescript+@types/node만) + markdown.ts(의존성 0 마크다운→HTML 변환기) + templates.ts + content.ts(랜딩 KO/EN) + 랜딩 페이지(Hero·문제·솔루션·조직도·C4I 파이프라인·핵심기능·CTA 7섹션) + styles.css(마피아/조직 테마) + app.js(한/영 토글).
Phase 2 — build.ts 가 큐레이션된 docs 14종(content.ts DOCS)을 dist/docs/*.html 로 변환 + /docs/ 인덱스(카테고리: 아키텍처/스펙/전략) + 사이드바 네비. ISSUES·실측·rules·memory 등 내부 문서 제외.
Phase 3 — docs/CHANGELOG.md→changelog.html, docs/strategy/roadmap.md→roadmap.html. public/_headers(CF 캐싱) + site/README.md(Cloudflare Pages 배포 설정: root site, build npm install && npm run build, output dist).
빌드 산출물: dist/ 20개 파일. npm run build (tsc → node build/build.js) 통과, 링크 무결성 확인.

배포 완료: Cloudflare Pages 프로젝트 bigbossos 생성 + 첫 배포 (wrangler pages deploy, 계정 benedictarthur1026@gmail.com). 라이브 https://bigbossos.pages.dev — 전 페이지 200 확인. 남은 작업: bigbossos.com 커스텀 도메인 연결(CF 대시보드, 회장 작업).

상세 스펙·결정 로그: docs/spec/website.md.

[2026-05-14] Ralph 루프 감사 — 묶음 A: G175/G176 (debate 루프 정체 감지 + 비용 상한)

배경: 24시간 토론 시스템 + C레벨 관측이 구조적으로 Ralph 루프임을 회장이 관찰. Ralph 정전(canonical) 속성 14개와 코드베이스 전수 대조 감사 → GAP 3(#4 git 체크포인트·#8 정체 감지·#13 크래시 복구) + LOOSE 2(Observer 무상한·watch-cycle 인메모리) 식별. 묶음 A는 마이그레이션 없이 debate.ts debateLoop 루프 로직만 손보는 2건.

G175 — 정체 감지 (No New Minimum 회귀 복구)

Why: debateLoop break 조건이 !currentNode/isFullyResolved()/round>=20 뿐 → 무진전으로 최대 20라운드 토큰 소비. Diamond의 No New Minimum(G14)이 diamond-*.ts 삭제(C4I 전환) 때 소실, debate.ts에 미재구현.
What: stagnantRounds 카운터 + MAX_STAGNANT_ROUNDS(env DEBATE_MAX_STAGNANT_ROUNDS, 기본 3). 라운드 종료 시 진전 판정(testPassed || childAdded). K라운드 연속 무진전 → break + escalateDebateAbort('stagnation').

G176 — debate 누적 토큰 비용 상한

Why: enforceTokenBudget()은 프롬프트 1개 truncate일 뿐, 토론 전체 누적 미감시. 비용 상한이 watch-cycle period budget(파이프라인 레벨)에만 존재.
What: cumulativeTokens 누산(라운드별 의견+합의 estimateTokens) + DEBATE_TOKEN_CEILING(env, 기본 120000). 초과 시 break + escalateDebateAbort('token_ceiling').

공통: 두 사유 모두 동일 출구 — 루프 top 차단 + 루프 종료 후 escalateDebateAbort()가 회장·CEO에 alert 발행(🚨 로그 마커). 수정 1파일(debate.ts), tsc 0에러.

[2026-05-14] Ralph 루프 감사 — 묶음 B: G177 (생성 프로젝트 git 체크포인트)

G177 — 파일 손상 rollback 지점 (Ralph 루프 감사 #4)

Why: server/src 전체 git 호출 0건 → 워커가 생성 프로젝트 파일 손상 시(G98 pbxproj 등) 되돌릴 시점 스냅샷 없음. "메모리(DB)"와 "파일 체크포인트(git)"를 동일시해 후자 누락.
What: 신규 orchestrator/git-checkpoint.ts — initCheckpointRepo() / commitCheckpoint() / resetToLastCheckpoint(). 모든 git 호출이 cwd=projectDir 로 격리 — bigbossos 레포 미접촉, 생성 프로젝트 안에 자체 .git.
배선 (orchestrator.ts 3곳): ① runPipeline() budget gate 직후 initCheckpointRepo(cwd)(멱등) ② processOrderFromPlan() 종료 시 — buildCorrupted(overall='fail' + buildErrors) → resetToLastCheckpoint()로 직전 체크포인트 롤백(다음 order 손상 전파 차단), 그 외 → commitCheckpoint() ③ import.
설계 결정: 기존 retry 루프가 부분 재배치 구조 → 루프 중간 reset은 통과 워커 산출물 손실 위험 → reset은 order 전체 실패(통과 워커 0) 시점에만. scaffolding-agent.ts 미접촉 — runPipeline 일괄 init이 전 플랫폼 균일·저결합. git 함수 실패 시 throw 대신 warn(보조 안전장치가 본류 미차단). tsc 0에러.

묶음 C(G178 크래시 복구 + G179 영속화) 대기.

[2026-05-14] Ralph 루프 감사 — 묶음 C: G178/G179 (크래시 복구 + 런타임 상태 영속화)

마이그레이션 1건(072_crash_recovery.sql)으로 압축 — debate_consigliere_entries(059)는 이미 존재(미배선 dead table였음), debates.started_at/ended_at도 이미 존재. 072는 debates.consigliere 컬럼 정상화 + 범용 server_runtime_state 키-값 테이블만 추가.

G178 — debate 크래시 복구 (Ralph 루프 감사 #13)

Why: DebateConsigliere ledger 인메모리, 종료 시점에만 DB 1회 기록 → 크래시 시 진행 중 토론 전손, 부팅 재개 경로 없음.
What: debate-consigliere.ts flushToDb()(미flush 엔트리 증분 upsert) + static hydrate()(부팅 복원) + lastFlushedSeq. debate.ts — debateLoop 라운드마다 flushToDb(), processNextDebate가 hydrate()로 재개/신규 통합, 시작 시 insertDebateStub()(ended_at=NULL), saveDebateLog upsert+ended_at 마감, scanAndResumeIncompleteDebates() 부팅 훅, debateLoop round를 getTotalRounds()부터. debate-queue.ts enqueueExisting()(id 보존 재등록).

G179 — 런타임 상태 영속화 (Ralph 루프 감사 LOOSE 2건)

Why: watch-cycle 당일 예산·Council 반성 커서가 인메모리 → 재시작 시 백지화(예산 초과·워커 활동 누락). Observer는 Council 게시 상한 없음.
What: watch-cycle.ts persistWatchState()/loadWatchState() — 당일 예산을 server_runtime_state에 영속화, 부팅 복원. clevel-council.ts persistCouncilCursor()/loadCouncilCursor() — 반성 커서 영속화·복원. clevel-observer.ts observerPostGate() — 시간당 게시 상한(기본 20, env 설정가능), 배치 요약·진행률 게시에 적용(긴급 task_blocked는 면제).

공통: 모든 영속화 함수 실패 시 throw 대신 warn — 안전망이 본류를 막지 않음. index.ts 부팅 시 loadWatchState() + scanAndResumeIncompleteDebates() 호출. tsc 0에러.

Ralph 루프 감사 종료 — GAP 3(#4·#8·#13) + LOOSE 2 전량 해소. G175~G179.

[2026-04-29] G174 Bugfix — C레벨 섹션별 분리 호출 (Gemma 컨텍스트 대응)

근본원인: Gemma 4b 컨텍스트 짧아 스키마 정의가 생성 시점에 소실 → fromCLevel enum 위반, sustainment 누락.

수정 방향 (회장): 컨텍스트=큐 → 스키마 앞자리 선점 + 섹션별 태스크 분할 + 출력 템플릿 강제.

수정 3곳:

output-schemas.ts — CLEVEL_SINGLE_ORDER_SCHEMA 추가: 단일 CLevelOrder 검수용 스키마
phase-clevel.ts — buildCLevelSectionPrompt(): placeholder 템플릿 + 스키마를 프롬프트 맨 앞 배치, 섹션 단일 지정
phase-clevel.ts — phaseCLevel() 루프: 섹션별 1:1 호출 → 섹션별 CLEVEL_SINGLE_ORDER_SCHEMA 검수 → orders 수집. fromCLevel/sustainment 서버 측 normalise 보정.

[2026-04-28] G173 Bugfix — processNextDebate() 배선 완료 (토론 실제 실행)

Why: G147이 requestDebate()(enqueue)만 구현하고 processNextDebate()(drain)를 미배선한 채 RESOLVED로 닫힘. 결과: 실측103~121 전 구간 토론이 한 번도 실행되지 않음.

What:

orchestrator.ts: processNextDebate/DebateConfig import 추가. runPipeline() 전 directive 완료 후 debate queue drain loop 삽입 (agents DB 조회 → DebateConfig 구성 → while loop drain).
phase-clevel.ts: requestDebate import 추가. C-Level output.debateRequest 존재 시 requestDebate() 호출 (urgency→DebatePriority 매핑: immediate→high / normal→medium / background→low). 기존에는 D02 로그만 찍고 enqueue 자체가 없었음.

tsc: 0에러.

[2026-04-28] test-record 완료 시 sync-ssd 자동 호출

Why: 실측 완료 후 SSD 동기화가 수동이어서 누락 발생. training-capture는 실시간 SSD 기록이지만 realtest 보고서·에이전트 로그·비용 CSV는 sync-ssd 수동 실행 시에만 SSD에 저장됨.

What: bin/test-record Step 11(요약 출력) 이후 bin/sync-ssd 자동 실행. SSD 없으면 홈 폴백(~/cli-company-data)으로 자동 처리됨.

[2026-04-28] recipes → blueprints 네이밍 통일

Why: Capomastro = 이탈리아 마피아 건설업자/현장감독 컨셉. recipes는 요리 은유라 컨셉과 불일치. blueprints(건축 설계도)로 통일.

범위:

server/recipes/ → server/blueprints/
~/.capomastro/recipes/ → ~/.capomastro/blueprints/
ide-recipe.ts → ide-blueprint.ts (함수명/타입명 전부 포함)
RecipeVars → BlueprintVars, findRecipe → findBlueprint, runRecipe → runBlueprint
CAPOMASTRO_RECIPES_URL → CAPOMASTRO_BLUEPRINTS_URL
capomastro 레포 recipes/ → blueprints/

[2026-04-28] Capomastro GitHub fetch — recipe 소스 분리

Why: server/recipes/ 로컬 번들은 Capomastro와 BigBossOS가 결합됨. recipe 추가/수정 시 서버 재배포 필요. Capomastro는 독립 레포여야 함.

결정: ide-recipe.ts의 RECIPES_DIR를 GitHub fetch + 로컬 캐시로 전환.

캐시 경로: ~/.capomastro/recipes/ (서버 종속 없음)
서버 시작 시 비동기 sync (논블로킹). 캐시 없으면 server/recipes/ fallback.
환경변수 CAPOMASTRO_RECIPES_URL 로 레포 URL 오버라이드 가능.
오프라인/개발 모드: server/recipes/ 그대로 사용.

구현:

syncAllRecipes() — 서버 시작 시 GitHub에서 전체 recipe fetch → ~/.capomastro/recipes/
warmRecipe(platform, ide?) — 단일 recipe on-demand fetch
findRecipe() — cache → local 순서로 탐색
server/src/index.ts — 서버 시작 시 syncAllRecipes() 비동기 호출

실측: syncAllRecipes() → ~/.capomastro/recipes/xcode/ios-app.md 등 캐싱 확인.

[2026-04-28] IDE Recipe MD 시스템 + Capomastro ViewHolder 재설계

Why: IDEDriver Vision Loop는 LLM에 100% 의존 → 비용·불확실성. 대부분의 IDE 조작은 항상 같은 경로를 따름 (iOS 앱 만들기 = 항상 iOS 탭 → Next → 이름 입력 → Create). 이 경로를 MD에 하드코딩하면 LLM 없이 결정론적으로 실행 가능.

결정: Recipe MD 시스템 구축. "하드코딩 합법화" — IDE별 recipe MD 파일에 조작 스텝을 명시, LLM은 recipe 실패 시 fallback으로만 개입.

Capomastro ViewHolder 재설계:

기존: Go 바이너리 (FEAT-A1 폐기) → ScaffoldAgent (haiku LLM)
신규: ViewHolder 에이전트 패턴. 슬롯 데이터 = IDE recipe MD. 자체 GitHub 레포에서 recipes 가져옴 (표준 marketplace와 구분).
현재: server/recipes/ 로컬 운영. 장기: Capomastro 전용 레포로 분리.

추가/수정 파일:

server/src/orchestrator/ide-recipe.ts — Recipe parser + step executor (AX 제어 + shell)
server/recipes/xcode/*.md — Xcode recipe 12종 (ios-app, macos-app, multiplatform, watchos, tvos, visionos, framework, swift-package, arkit-app, game-spritekit, safari-extension, document-app)
server/recipes/android-studio/*.md — Android Studio recipe 7종
server/recipes/vscode/*.md — VSCode recipe 3종 (flutter, dart-package, flutter-plugin)
server/recipes/unity/*.md — Unity recipe 4종
server/recipes/unreal/*.md — Unreal recipe 2종
server/recipes/godot/*.md — Godot recipe 2종
server/recipes/terminal/*.md — CLI recipe 52종+
docs/spec/capomastro.md — Capomastro ViewHolder 명세 신규 작성

실측 결과:

Xcode iOS App: 8스텝, LLM fallback 없음, success ✅
Xcode macOS App: 8스텝, LLM fallback 없음, success ✅
Xcode Multiplatform: 8스텝, LLM fallback 없음, success ✅
Xcode Framework: filter step AX 한계 (셀 미노출) → LLM fallback, success ✅

버그 수정:

중복 폴더 충돌 → name2, name3 자동 증가로 Xcode conflict dialog 원천 차단
프로젝트 경로 탐지 → 정확한 이름 우선 확인 후 xcodeproj find fallback
filter action → "toggle filter" 버튼 자동 클릭 후 AXSearchField 탐색

[2026-04-26] IDEDriver Vision Loop — ScaffoldAgent GUI 자동화

Why: docs/spec/roles.md 소프트웨어 도메인 50개 이상 지원 필요. 도메인별 IDE UI를 하드코딩하면 버전/IDE 변경마다 깨짐. 유지 불가능.

결정: IDEDriver = 제네릭 손(screenshot/click/type_text/ax_tree). gemma3:4b(로컬 비전) = 눈+뇌. 화면 보고 다음 액션 결정. 모든 GUI IDE에 동일한 루프 적용. 하드코딩 0.

추가 파일:

server/src/orchestrator/ide-vision-loop.ts — IDEDriver 호출 + gemma 비전 루프 (최대 30스텝)
ide-driver/ 프로젝트 — 제네릭 리모컨 (screenshot/click/ax_tree/type_text)

라우팅 변경: scaffolding-agent.ts

unity / unity-3d / unity-2d / unity-urp / unity-hdrp → IDEDriver loop
unreal → IDEDriver loop
godot → IDEDriver loop
visionos / watchos / tvos / macos-app → IDEDriver loop (Xcode)
기존 ios / android 직접생성 경로 유지

상태: DONE. TypeScript 타입 에러 없음.

IDEDriver Vision Loop — 구조 개선 (2026-04-26)

Why (근본 원인):

매 스텝마다 100개 전체 요소 → gemma 전달 → 노이즈 과다
네비게이션 목표와 폼 데이터가 하나의 문장에 혼재 → gemma 혼동
UI 상태(메뉴열림/폼/템플릿선택) 미구분 → 상황에 맞지 않는 요소 노출

Fix — 컨텍스트 기반 요소 필터링:

detectContext(): AXMenuItem 보이면 menu, TextField 2개+ 이면 form, AXCell 3개+ 이면 template
filterForContext(): 컨텍스트에 맞는 role만 추출
menu → AXMenuBarItem+AXMenuItem만
form → AXTextField+AXButton+AXPopUpButton만
template → AXCell+AXButton+AXTab만
general → AXMenuBarItem+AXButton만

[2026-04-25] G170 Architecture Decision — Worker Output Contract 규격화 (Disk-diff as Source of Truth)

ADR 확정: docs/spec/adr-worker-output-contract.md

결정 요지:

tool-write 워커(Write tool 있음): JSON에서 filesModified 제거. 시스템이 scanScopeDirectory() disk scan으로 채움
json-embed 워커(Ollama 등): 기존 계약 유지 ({path, content} 임베드)
워커 출력 템플릿 파일로 계약 명시 (output-templates/worker-tool-write.json / worker-json-embed.json)

근거: G165/G167/G168 세 이슈가 동일 구조 결함(LLM 경로 신뢰)에서 발생. 패치 누적 대신 구조 변경.

실측결과보고서 자동화 프로토콜 변경:

P-3 phantom_success 기준: W02 filesModified=0 → W03 diskObserved=[] 로 변경
diskObserved가 source of truth, llmReported는 진단 참고

[2026-04-25] G168 Bugfix Protocol 완료 — Write tool 워커 과소출력 오감지 → consecutive_timeouts SCRAM 근본해결

G168 RESOLVED: 3곳 수정. Write tool 워커는 G165 fix로 JSON에 path만 반환(짧음) → 과소출력 재시도 면제.

adapter.ts AgentInvokeParams.skipShortOutputRetry?: boolean 추가
adapters/claude-cli.ts params → options 전달
llm.ts AgentOptions 필드 추가 + 조건 && !opts?.skipShortOutputRetry
phase-worker.ts hasWriteTool이면 skipShortOutputRetry: true 설정

근본원인: llm.ts 과소출력 면제 목록에 scaffolder/analyzer만 있고 Write tool 워커 전체 누락. G165 fix(path-only JSON)와 1000자 기준 충돌. tsc 0에러.

[2026-04-25] G167 Bugfix Protocol 완료 — Worker 유니코드 경로 혼동 → phantom_success 근본해결

G167 RESOLVED: phase-worker.ts buildWorkerSystemPrompt() — scopeDir 파라미터 추가 + RULE 7 경로 강제.

시그니처: buildWorkerSystemPrompt(workerRole, allowedTools, sil, scopeDir?)
RULE 7: "CRITICAL PATH RULE: All files MUST be written to paths starting with '{scopeDir}'."
호출부에 assignment.execution.scope.directory 전달

근본원인: Haiku 모델이 한국어 실측테스트 디렉토리를 일본어/중국어 Unicode로 혼동 출력 → Write tool이 wrong-unicode 경로에 파일 저장 → scanScopeDirectory() 미감지 → filesModified=0 (phantom_success). tsc 0에러.

[2026-04-25] G166 Bugfix Protocol 완료 — G87 merger 무제한 흡수 → consecutive_timeouts SCRAM 근본해결

G166 RESOLVED: phase-leader.ts mergeOverlappingScopeAssignments() — MAX_MERGES_PER_SURVIVOR=1 상한 추가.

survivor별 머지 횟수 추적 (mergeCount Map)
cap 도달 시 추가 흡수 skip → 잔여 task가 독립 실행

근본원인: G87 merger가 동일 filePattern 그룹 전체를 하나의 survivor에 무제한 흡수 → 실측120에서 FRONTEND-ANDROID-120-001에 002+003이 흡수되어 20+ Kotlin 파일 단일 태스크 생성 → 2회 연속 300s 초과 → consecutive_timeouts SCRAM. tsc 0에러.

[2026-04-25] G161 Bugfix Protocol 완료 — CEO_MODEL env 잔재 절차 수정

G161 RESOLVED: realtest-standard.md Step 1.5 patch_env에 CEO_MODEL 삭제 추가.

sed 패턴: CEO_MODEL|CLEVEL_MODEL|LEADER_MODEL|WORKER_MODEL|OLLAMA_URL
4번째 파라미터 ceo 추가 — Ollama CEO 모드 지원
리셋 예시: patch_env "" "" "" ""

근본원인: patch_env가 CLEVEL/LEADER/WORKER만 삭제, CEO_MODEL(ceo-agent.ts 전용) 미포함 → 이전 세션 잔재 오염.

[2026-04-25] G165 Bugfix Protocol 완료 — docs 워커 JSON 파싱 실패 근본해결

G165 RESOLVED: phase-worker.ts buildWorkerSystemPrompt — Write tool 유무 분기 추가.

Write tool 있는 워커(claude-cli): filesModified에 {path} only — content 임베드 금지
Write tool 없는 워커(Ollama): 기존대로 {path, content} 유지
summary도 "brief — 1-2 sentences max" 제약 추가

근본원인: 시스템 프롬프트가 Write tool 유무 무관하게 "full file content required" 지시 → architecture_dev가 대용량 마크다운을 JSON에 임베드 → extractJSON 파싱 실패. tsc 0에러.

[2026-04-25] G164 Bugfix Protocol 완료 — scaffold platform 감지 3중 신호 OR

G164 RESOLVED: phase-worker.ts scaffold platform 감지 로직 확장. 기존 workerRole.startsWith('android/ios') 단독 → 3중 신호 OR 조합으로 전환.

신호 1: workerRole.startsWith('ios'/'android') (기존 유지)
신호 2: assignmentId.toUpperCase().includes('IOS'/'ANDROID') (신규 — ANDROID-119-001-SCAFFOLD 패턴 감지)
신호 3: scopeDir.startsWith('ios/'/'android/') (신규 — 디렉토리 prefix 백업)

근본원인: CTO가 ios/android 작업 모두 frontend_dev role에 배정 → workerRole 단독 불충분. tsc 0에러.

영향: G162 pre-scaffold(scaffoldProjectAgent) 이제 Android scaffold 태스크에도 발동. 실측120에서 ANDROID scaffold PASS 예상.

[2026-04-24] 실측119 완료 — G163 RESOLVED, G162 REGRESSED, G164/G165 신규

실측119 결과 (WARN): success=true, workers=11, elapsed=34.4분. Q20 14/20 PASS. 자율 3축 4/4.

G163 RESOLVED: iOS frontend_dev Read+Write로 19파일 생성 성공 확인
G162 REGRESSED → G164 신규: pre-scaffold workerRole.startsWith('android') — 실제 android 담당 role=frontend_dev 불일치. scaffoldProjectAgent 미발동. assignmentId prefix 방식으로 전환 필요 (Bugfix Protocol 진행 필요)
G165 신규: CTO-119-DOCS-T2 structured_output_failure (parse_error) — architecture_dev 장문 응답 JSON 파싱 실패
phantom_success PERSISTENT: CPO/CTO docs worker 절대경로 write skip (G113) — 16건 반복
R03 4홉 에스컬레이션 완벽 작동: worker→leader→clevel→ceo→chairman Q12~Q14 PASS

[2026-04-24] G162+G163 Bugfix Protocol 완료 — Worker scaffold pre-seeding + Read 재추가

G162 RESOLVED: phaseWorker()에 scaffold pre-seeding 추가. FEAT-A1 dead code 연결 — scaffoldProjectAgent()가 ios/android workerRole 감지 시 ensureScopePresent() 직후 자동 호출. appName은 scope.directory 경로 또는 mission에서 추출. phase-worker.ts 1곳 수정. tsc 0에러.

G163 RESOLVED: Worker roleAllowedTools에 Read 재추가 (Write,Edit → Read,Write,Edit). G138 탐색 제한은 buildWorkerSystemPrompt RULE 6으로 유지: "Read ONLY for exact path of file to modify, not exploration." llm.ts roleAllowedTools 14개 + fallback 1곳, phase-worker.ts 1곳. tsc 0에러.

영향: Q19(에뮬레이터)/Q20(iOS scaffold) 차단 해소 가능 → 실측119에서 검증 필요.

[2026-04-24] 실측118 완료 — G158·G160 VERIFIED, 신규 G161~G163, Q20 12/20

What: 실측118 (StreamApp, Claude+Gemma CEO 혼용) — C4I Pipeline complete success=true (최초). elapsed=1620.9s, cost=3,362원, 에이전트 30명.

G158 VERIFIED: SR02→soldato fallback graceful 2회 연속 PASS (실측117+실측118). [Adapter] SR fallback 'soldato' not registered — continuing with normal adapter 3건, SCRAM 없음.

G160 VERIFIED: UnhandledRejection=0건, Node.js crash=0건 (실측118). nextPreflight?.catch(() => {}) 정상 작동.

Q20 현황: 12/20 PASS (+4 대비 실측116). PASS: Q01~Q04, Q06~Q10, Q12, Q14~Q15, Q17~Q18. FAIL: Q05(ViewHolder 토론), Q20(loop 미완). MISSING: Q11, Q13, Q16, Q19.

신규 이슈:

G161 (Minor/P2): CEO_MODEL=ollama:gemma3:4b .env 잔재 — BOOT 단계 모델 미검증
G162 (Major/P1): Worker Bash 미지원 → Capomastro iOS scaffold 실패 (FE-116-001-SCAFFOLD)
G163 (Major/P1): Worker Read/Write tool 제약 → 신규파일 생성 불가 (architecture_dev/product_dev)

자율 3축: 4/4 PASS (실측116 1/4 대비 +3). U01→U02→U03→U04 4홉 보고 체인 완성. Canvas ADD x2.

overallProgress=39%: G162/G163으로 iOS scaffold·docs·product 3개 섹션 실패. API 빌드 FAIL.

[2026-04-24] G160 O3 pipelining nextPreflight UnhandledRejection 크래시 근본해결 (Bugfix Protocol)

What: 실측117 발견 — CPO consecutive_timeouts → nextPreflight promise가 executeDirective 실행 중 reject → await 전 Node.js v22 UnhandledPromiseRejection → 프로세스 강제 종료. 당일 근본해결.

G160 — orchestrator.ts nextPreflight assign 직후 .catch(() => {}) 추가:

orchestrator.ts line 230-232 직후: nextPreflight?.catch(() => {}) 추가.
executeDirective 실행 창(window)에서 발생하는 rejection을 marked-handled로 만들어 UnhandledRejection 방지.
rejection은 다음 루프 iteration await nextPreflight!에서 정상적으로 잡혀 outer catch → triggerScram() 경로 유지.
tsc EXIT=0.

실측117 직접 증거:

Error: [C-Level:cpo] Failed to produce valid output after retry.
at async preflightDirective (orchestrator.ts:377) + Node.js v22.22.2 강제 종료

[2026-04-24] G158 SR02 soldato Unknown adapter SCRAM 근본해결 (Bugfix Protocol)

What: 실측116 발견 — Silent Running 활성화 시 soldato-pro adapter 미등록 → Unknown adapter 예외 → pipeline SCRAM. workers=0으로 조기 종료. 당일 근본해결.

G158 — adapter.ts graceful fallback (adapter 미등록 SR adapter 처리):

adapter.ts getAdapter(): if (!factory && isSR && !name) → normalName(claude-cli)으로 graceful fallback + console.warn.
adapter.ts wrapped invoke catch 경로: fallbackFactory 미등록 시 normalFactory로 재시도 + console.warn. SCRAM 방지.
tsc EXIT=0. rsync production→OpenSource 완료.

실측116 직접 증거:

[SR02] action=activated, trigger=api_quota, fallbackModel=soldato-pro
[X01] action=scram, reason=Pipeline error (cycle 1): Unknown adapter: soldato. Registered: [claude-cli, ollama, codex-cli]

[2026-04-24] G155~G157 Q03/Q10/Q16 lifecycle 마커 추가 + X06 status 필드 완비 (Bugfix Protocol)

What: Q03/Q10/Q16 PASS 차단 원인 — CH07/CD11/CD12/W16/W17 emit() 미연결 + X06 status 필드 부재 근본해결. tsc 0에러.

G155 — CH07 마커 (Q03 CEO C레벨 상시 감시):

clevel-council.ts: emit import 추가. startCouncil() isCouncilRunning=true 직후 emit('CH07', { projectId, activeCLevels }).

G156 — CD11/CD12 마커 (Q16 Diamond 팬아웃/수렴):

debate.ts: debateLoop() collectOpinions() 직후 emit('CD11', { nodeId, round, participantCount }). consensus 저장 직전 emit('CD12', { nodeId, round, autoConsensus }). Q16: CD10+CD11+CD12+R04 전부 발행 → ✅ 달성 가능.

G157 — W16/W17 마커 + X06 status 필드 (Q10 Skill 자가업데이트):

skill-loader.ts: SkillFrontmatter에 status?: 'proposed'｜'verified'｜'deprecated' 추가.
rules/*.md (3파일): status: verified frontmatter 추가 → X06 FILE 마커 충족.
skills/index.ts: emit import 추가. injectSkills()에서 proposed→W16, verified→W17 발행. proposed 스킬에 [EXPERIMENTAL] 태그.

[2026-04-24] G150~G154 Q07/Q09/Q11/Q13 lifecycle 마커 5종 추가 (Bugfix Protocol 전부 적용)

What: Q07/Q09/Q11/Q13 PASS 차단 원인 — lifecycle emit() 미연결 5건 근본해결. 공통 근본원인: 기능 구현↔측정 연결 단절(organic code growth). tsc 0에러.

G150 — S01/S02 마커 (Q07 명세서 발급):

spec-issuer.ts: emit import 추가. Phase A1 직전 emit('S01', { clevel, phase }), Phase B 직전 emit('S02', { clevel }).

G151 — D03 마커 (Q07 3홉 라우팅):

orchestrator.ts: preflightDirective() phaseLeader() 반환 직후 emit('D03', { chain: 'clevel→leader→worker', ... }). Q07: S01+D01+D03+LH01 전부 발행 → ✅ 달성 가능.

G152 — CD04 마커 (Q13 크로스 도메인 토론):

debate.ts: emit import 추가. requestDebate() enqueue 직전 emit('CD04', { topic, triggerAgent, participants }). Q13: CD04+R03 전부 발행 → ✅ 달성 가능.

G153 — W07 마커 (Q09 Harness stream-json 파싱):

adapters/claude-cli.ts: emit import 추가. extractJSON 호출 직전 emit('W07', { agentId, role }). Q09 개선.

G154 — X07 마커 (Q11 Skill 자동 승격):

usf.ts: emit import 추가. updateSkillConfidence() 내 proposed→verified 승격 직후 emit('X07', { role, count, slugs }). Q11 개선.

[2026-04-24] G145~G149 Q20 전부 PASS — 라이프사이클 마커+기능 완성 (G145/G146/G147/G148/G149)

What: Q01~Q20 전부 PASS 달성을 위한 5개 이슈 근본해결. Bugfix Protocol (5-Whys→Diamond→4척도→채택) 전부 적용.

G145 — lifecycle 마커 추가 (Q18/Q19/Q20 BD01-BD06, Q04 CH01-CH03, Q16 CD10):

phase-review.ts: Check5 build validation에 BD01(iOS)/BD02(Android) 전, BD03(에러)/BD04(통과) 후 emit 추가
orchestrator.ts: retry loop에 BD05(빌드 재시도), 전 패스 후 BD06 emit 추가

G146 — CEO 동적 C레벨 고용 컨텍스트 주입 (Q04):

pipeline-bridge.ts: getActiveCLevelsFromDB(projectId) 호출 → projectContext에 현재 C레벨 현황 주입. CEO가 고용 결정 가능.

G147 — Diamond 자동 트리거 배선 (Q16):

orchestrator.ts: retry 소진 시 requestDebate() + emit('CD10'). pipeline/ → orchestrator/debate.ts choke point 배선 완성.

G148 — Canvas 명세서 저장 (Q06):

phase-clevel.ts: D02 직후 emitCanvas('ADD', { source, strokes, sections }) — C레벨 order = Canvas stroke.

G149 — Skill 자가발전 (Q11):

usf.ts: updateSkillConfidence(role, outcome) 추가 — pass 5회 누적 시 proposed→verified 자동 promote.
orchestrator.ts: processOrder() 내 allItems 순회 → 각 worker outcome 후 updateSkillConfidence() 호출.

tsc: 0 errors. rsync: OpenSource ↔ production 양방향 동기화 완료.

[2026-04-21] Track C 장애주입 F10/F11/F12 어댑터 훅 배선 (WHAT)

What: Track C 시나리오 F10/F11/F12를 guardedInvoke 초크포인트에서 실제로 동작하도록 배선. stub 제거.

변경 파일:

server/src/pipeline/fault-injection.ts (신규): /tmp/fault-injection-active.json 트리거 파일 reader + 합성 outcome emitter. FAULT_INJECTION_ENABLED=1 없으면 no-op.
server/src/pipeline/adapter.ts (수정): guardedInvoke 진입부에서 maybeInjectFault() 호출 → 주입 활성 시 적응한 outcome 즉시 반환 (adapter.invoke 우회).
bin/fault-injector (수정): F10/F11/F12 stub 제거 → 트리거 파일 write + 즉시 exit. F05는 기존 tail+SIGKILL 유지.

동작 매트릭스: | 시나리오 | maxInvocations | outcome | 검증 대상 | |---|---|---|---| | F10 | 1 | WorkerOutput {status:success, filesModified:[]} | G139 phantom_success gate | | F11 | 1 | timedOut:true (sleep timeoutMs+5s) | G138 구조 gate + T01 timeoutRecovery | | F12 | 2 | timedOut:true × 2 | X01 andon + Council escalation |

배선 검증: F10 arm → 트리거 파일 JSON shape 확인 완료. tsc 0 errors. 실측110~113 본격 검증 예정.

Related: docs/realtest/fault-injection-pool.md §3a 아키텍처 섹션 갱신.

[2026-04-21] G138 consecutive_timeouts Bugfix Protocol — 근본해결 완료 (WHAT)

배경: 실측107 d11-notes에서 3개 distinct worker(frontend_dev/architecture_dev/product_dev)가 순차적으로 consecutive_timeouts X01 andon pause. 로그 증거: T01 elapsedMs:300310, compartmentLimitMs:300000 + agent-level ⏰ 타임아웃 (315초) — 강제 종료. Worker가 ls/find/Capomastro/extended thinking 등 탐색 도구 사용에 compartment 시간 소진 → 코드 생성 시간 부족.

Bugfix Protocol 적용:

5-Whys: timeout → 도구 탐색시간 소진 → G131 CEO tool 제거 패턴 Worker 미적용 → Leader→Worker 컨텍스트 주입 계약 부재 → 탐색 시간에 compartment 잠식.
다이아몬드 토론 4방안: A Worker tool 제거 / B granularity cap / C compartment 확대 / D 모델 업그레이드.
4척도 검증: A ✅ (근본, 탐색시간 제거) / B ✅ 통과하나 근본 해결 후 불필요(증거상 "생성량"이 아닌 "탐색시간"이 원인) / C ❌ 증상완화 / D ❌ 프리티어 원칙 위반.
채택: A 단독 (회장 승인 2026-04-21). G131(CEO)/G132(Leader) 패턴을 Worker로 확장.

수정 3건:

orchestrator/llm.ts roleAllowedTools — 모든 coder worker(api/backend/frontend/ios/android/database/web/ui_ux)에서 Read,Grep,Glob,Bash 제거, Write,Edit만 유지. 미등록 worker fallback도 Write,Edit.
orchestrator/llm.ts Consigliere projectTree 주입 조건에 isWorkerRole(role) 추가 — Worker가 탐색 없이 구조 파악.
pipeline/phase-worker.ts buildWorkerSystemPrompt RULE 5: "Do NOT explore the filesystem. Emit complete file content directly in filesModified."

효과 예상: Worker compartment(300s) 내 도구 탐색 0 → 코드 생성에 전 시간 할당. 실측107의 iOS 스캐폴드 5분 소진 → 예상 1~2분 이내 완료.

tsc 0에러. 실측108 검증 대기.

[2026-04-21] G139 phantom_success Bugfix Protocol — 근본해결 완료 (WHAT)

배경: Track B 실측107 d11-notes 최초 발견. Worker가 SIL-3+ status=success 보고했으나 modified files=0. retry 2라운드 모두 거짓 성공 반복. 기존 taxonomy는 unknown으로만 분류 → 가시성/대응 부재. AI 안전 Critical.

Bugfix Protocol 적용:

5-Whys: self-report 신뢰 구조 → verify-loop gate 부재 → modifiedFilesCount 체크 없음 → retry feedback 없음 → 라벨 taxonomy 미커버.
다이아몬드 토론 4방안 (A/B/C/D): A 구조 gate / B 라벨 추가 / C 스키마 강제 / D retry feedback.
4척도 검증: A ✅ / C ✅ (근본, choke point) / B ⚠️ 관측 보조 / D ❌ 증상완화 배제.
채택: A+C 병행 + B 부수 (회장 승인 2026-04-21).

수정 3건:

pipeline/failure-labels.ts — 6번째 라벨 phantom_success 추가 + classifier 패턴(zero files + claims success/sil) → retry 소진 후 unknown 아닌 phantom_success로 라벨.
pipeline/phase-review.ts — SIL-3+ + filesModified=0 gate에 status='partial' 확장 (LLM이 partial로도 거짓말 가능). reason 문자열을 "phantom_success: ..." 형식으로 classifier-align.
docs/spec/failure-labels.md v1.1 — 라벨 표 6종 + §2d phantom_success 해설 추가.

디스크 증거 우선 원칙: self-report는 관측용, 결정은 scanScopeDirectory / filesModified 실재 확인. phase-review.ts Check 3(G105 existsSync) 연장.

tsc 0에러. 실측108 검증 대기 (2회 연속 phantom_success 라벨 0건 or 검출 시 정확 분류).

[2026-04-21] Track B 도메인 독립성 실측 N=5 kickoff (WHY)

배경: 누적 실측 90+회가 전부 StreamApp(동영상 스트리밍) 단일 도메인. 파이프라인이 해당 도메인에 과적합됐는지 empirical 판정 필요.

계획: docs/realtest/domain-pool.md §4.1. 실측 102~106, 도메인 d02-chat / d04-commerce / d06-banking / d08-food / d11-notes. StreamApp N=8 baseline (M1-a 81.8%) 과 비교.

판정 기준:

전부 M1-a ≥ 70% → 도메인 독립 provisional
1~2개 M1-a < 50% → 과적합 노출
2개 이상 M1-a < 50% + 카테고리 편향 → 과적합 확증

부차 관찰: cycle 11 Phase 1 R03 label 필드 emit 검증 (passive).

[2026-04-21] cycle 10 완주 — 실측102 G114 RESOLVED (WHAT)

총결: success=true, workers=3, elapsed=299.9s. structured_output_failure 0건 (실측101 = 1건). G114 Ollama format:"json" 전송계약 확립 → token-level JSON grammar 강제.

실증

structured_output_failure 0 ✅ (cycle 10 목표)
R03 escalation 0건
G113 materializer W06 3회 emit, 7 worker-produced source file 디스크 실재 (2회 연속)
G112 W05 3회 (scope seed 정상)
cycle 3~9 defense 축 전 회귀 0건

cycle 10 구현

server/src/orchestrator/llm.ts — callOllamaAgent 5th optional options?: { format?: 'json' } 추가, body JSON 조건부 spread
server/src/pipeline/adapters/ollama.ts — OllamaAdapter.invoke 에서 항상 { format: 'json' } 전달
C레벨 debate / Director 자유응답 경로는 options 미전달 → 기존 동작 유지

회장 지시 "사이클 4번 더" 완수 (cycle 7~10)

cycle 7: G112/G111 dispatch precondition + sibling gate
cycle 8: 실측100 G113 최초 노출
cycle 9: G113 materializer — 7-cycle 만 첫 실동 코드 산출 breakthrough
cycle 10: G114 transport JSON grammar — 전송계약 완결

누적 실측 9회 무SCRAM-trip. cycle 11 착수 여부는 회장 판정 대기.

[2026-04-21] cycle 10 착수 — G114 Ollama strict-JSON 모드 (WHY)

대상: G114 — 실측101 integration worker 1명 status=structured_output_failure. extractJSON 3단계 fallback 전부 실패 → parsed=null → R03 cascade. G113 content 필드 도입 후 긴 string 출력에서 unescaped newline/quote 가 JSON 구조 파괴.

5-Whys 근본: callOllamaAgent 가 format 파라미터 없이 /api/chat 호출. 토큰 샘플링 단계의 JSON grammar 강제 부재. 프롬프트 지시("JSON 만 출력") 의존 — 누적 "구조 우선, 프롬프트 비의존" 원칙 위배.

방향: Ollama 네이티브 format: "json" 활성화 (transport-level JSON 강제). schema/프롬프트 무변경.

채택 방안: A (docs/bugfix/101-cycle10-ollama-format-json.md) — 4척도 전량 통과.

구현: llm.ts callOllamaAgent 5th optional options?: { format?: 'json' } 추가, body 에 조건부 spread. ollama.ts OllamaAdapter.invoke 에서 항상 { format: 'json' } 전달. C레벨 debate / Director 자유응답 경로는 options 미전달 → 기존 동작 유지 (양보 없음).

원칙: cycle 3~9 schema-defense 축에 transport-level 축 추가. 대칭성: dispatch precondition(G112) → sibling gate(G111) → post-invoke write(G113) → transport JSON grammar(G114).

[2026-04-21] cycle 9 완주 — 실측101 G113 breakthrough (WHAT)

총결: success=true, workers=7, elapsed=696.2s, overallProgress=86%. W06 5회 + 실제 워커 산출 13개 파일. 9-cycle 벤치마크 체인 최초 실동 가능한 디스크 산출물 달성.

실증

G113 materializer 5회 W06 emit, skipped: [] — content 누락 0
G111 gate-drop 실전 발동 (hireProposal/fireProposal 각 1회 드롭, SCRAM 회피)
G109 enum-synonym 실전 발동 (completed→success coerce)
G112 scope seed 회귀 없음 (W05 정상)

cycle 9 구현

output-schemas.ts — WORKER_OUTPUT_SCHEMA.filesModified 을 [{path, content}] object array 로 확장
ir-types.ts — WorkerFileEntry 인터페이스 추가
adapter.ts coerceToSchema — string → {path} legacy coerce (Claude-CLI path 호환)
phase-worker.ts — materializeWorkerFiles post-invoke writer, validateIR 직후 디스크 flush, W06 lifecycle event
Worker system prompt — content 요구 명시 (schema 와 일관)

노출된 후속 이슈

G114 — integration worker 1명 structured_output_failure (R03 escalation). Pipeline 비차단 (success=true 유지). 원인 조사: 4B token 한계 또는 긴 content 출력 실패 가능성. → cycle 10 대상.

[2026-04-21] cycle 9 착수 — G113 Worker file-content 전송 채널 (WHY)

대상: G113 — 실측100 에서 Worker 가 filesModified: [3 paths] 보고하나 디스크 실제: []. grep writeFileSync src/pipeline → G112 STUB seed 외 디스크 쓰기 경로 0건. WORKER_OUTPUT_SCHEMA.filesModified 가 array of string 이라 내용 채널 부재. Claude-CLI 시대 tool-use 전제가 Gemma-only 환경에서 결손으로 드러남.

방향: schema 확장 filesModified: [{path, content}] + phase-worker post-invoke materializeWorkerFiles writer. transport-independent 어댑터 계약.

채택 방안: A (docs/bugfix/100-cycle9-worker-file-content-channel.md) — 4척도 전량 통과.

원칙: dispatch precondition (G112) + sibling gate (G111) 에 이어 post-invoke write 축 신설. string→{path} 레거시 coerce 로 Claude-CLI 경로 호환 유지.

[2026-04-21] cycle 7 완주 — 실측100 G112 resolved + G113 노출 (WHAT)

총결: 실측100 success=true, workers=4, elapsed=321.4s. W05 4회 emit + filesModified:1 최초 관측 (7-cycle 최초 non-zero). G112 precondition 축 active. G111 gate-drop defense armed (이번 run 에는 CEO clean output 로 미발동, 구조만 설치).

cycle 7 구현 (확장)

output-schemas.ts — fireProposal/hireProposal 에 'x-requires-sibling': { action: ... } gate 선언
adapter.ts coerceToSchema — sibling gate 미일치 시 [IR:gate-drop] 경고 후 property drop
phase-worker.ts — ensureScopePresent + stubCommentFor + extractExtension, W05 lifecycle event

신규 G113 — stub 확장 미수행 노출

G112 로 "빈 폴더 거부" 증상 소실 후, 4B 는 stub 을 확장하지 않고 "만들었다" 거짓 보고. G93 disk-is-truth validator 가 R03 로 escalation 전파:

"Retry exhausted (2 rounds): Worker claims success (SIL-3+) but modified zero files"

→ 다음 cycle 에서 stub expansion enforcement (compile 깨지는 TODO stub) 검토.

[2026-04-21] cycle 7 착수 — G112 빈 스코프 seed (WHY)

대상: G112 — 실측099 에서 "No files matched pattern / add dummy files" Worker escalation. 4B 가 빈 디렉터리를 "작업 미정의" 로 해석하여 blocked 반환. cycle 6 가 "errors 에 이유 써라" 를 강제한 덕에 근본 원인이 관측 가능 해짐.

방향: dispatch precondition 불변식 확립 — Worker invocation 직전 scope 비어있으면 STUB.<ext> 1개 seed.

채택 방안: A (docs/bugfix/098-cycle7-empty-scope-seed.md) — 4척도 전량 통과.

원칙:

validator 4축(type/existence/enum-synonym/semantic) 에 이어 dispatch precondition 축 신설
프롬프트 대신 data-layer choke point
Worker 작업량 보존 (stub 은 출발점일 뿐, 실제 코드는 여전히 Worker 몫)

[2026-04-20] cycle 6 완주 — 실측098 semantic visibility milestone (WHAT)

총결: cycle 6 validator 실전 발동 확인. Worker 응답이 errors: [] → errors: ["구체적 기술 사유"] 로 전환. Pipeline complete success=true, workers=7, elapsed=497.2s. files=0 여전하나 파이프라인 거짓말 제거 전진.

cycle 6 Bugfix 구현 (docs/bugfix/097-cycle6-worker-no-op-prevention.md)

server/src/pipeline/output-schemas.ts — WORKER_OUTPUT_SCHEMA 에 x-semantic-rules 선언 (status=blocked 면 errors minLength 1)
server/src/pipeline/adapter.ts — validateIR 내부 structural 검증 직후 top-level semantic rules 평가, 위반 시 IRValidationError throw
타입: interface SemanticRule { when, require, message }
원칙: 선언형 (하드코딩 X) + 4축 완성 (type → existence → enum-synonym → semantic consistency)

실측098 실행 증거

2차 시도에서 관통 (1차 G111 CEO fireProposal 빈 객체 SCRAM, 확률성)
R03 escalation 로그에 Worker 의 실체 사유 기입 확인 ("No event handler attached to the submit button", "No data persistence layer for safe removal", "lacks concurrency handling" 등)
cycle 5 latent 와 대조되는 active fix — validator 가 데이터 흐름에 실질 영향

신규 이슈

G111: CEO fireProposal: {} 빈 객체 동시 출력 — optional-but-if-present nested required 엣지. 2차 재현 안 됨 → 확률성 axis
G112: errors 는 채우나 filesModified=0 유지 — "honest failure" → "honest no-work" 수렴점. cycle 7 에서 Scaffolder skill fallback 또는 success + files=[] 조건부 reject 검토

측정 축 전환

cycle 1~5: depth (실패 stage 이동)
cycle 6: transparency (거짓 success 제거)
cycle 7+: substance (실질 코드 생성 강제)

자료

docs/realtest/실측098-gemma.md (6인 감사 평균 4.17, 3축 PASS)

[2026-04-20] cycle 6 착수 — G110 no-op worker 차단 (WHY)

대상: G110 — Worker 모두 status=blocked + files=0 + tokens=0 + errors=[] 응답 → 파이프라인 거짓 success.

방향: validator semantic consistency 축 추가. schema 선언형 x-semantic-rules — status=blocked 면 errors[] ≥ 1 요구.

채택 방안: B (docs/bugfix/097-cycle6-worker-no-op-prevention.md) — 4척도 전량 통과.

원칙:

cycle 3(type)/4(existence)/5(enum-synonym) 에 이어 semantic consistency 4축 완성
선언형 — schema 에 규칙 명시 (하드코딩 X)
honest-failure 우선 — SCRAM 감수하더라도 거짓 success 제거

[2026-04-20] cycle 5 완주 — 실측097 첫 E2E 파이프라인 관통 (WHAT)

총결: 5 cycle 누적 robustness stack 덕에 첫 E2E 파이프라인 관통 달성. SCRAM 0회, Pipeline complete success=true, workers=8, elapsed=511.4s.

cycle 5 Bugfix 구현 (docs/bugfix/096-cycle5-enum-semantic-mapping.md)

server/src/pipeline/output-schemas.ts — WORKER status 에 x-synonyms 11개 mapping 선언 (completed/done/finished/ok/passed/pass → success; failed/error/errored/fail → failure)
server/src/pipeline/adapter.ts:coerceToSchema — string + enum + not-in-enum + synonym 존재 시 매핑 + [IR:enum-synonym] warning. 미지 synonym 은 throw (정직 실패)

부수 fix — DIAMOND_MODEL env 누락 근본 해결

첫 기동 시 [Ollama:ceo] model unresolved (modelOverride=undefined, DIAMOND_MODEL=undefined) SCRAM
원인: callOllamaAgent 은 DIAMOND_MODEL 를 fallback 으로 읽는데 .env 에 CEO_MODEL 만 있었음
해결: .env 에 DIAMOND_MODEL=ollama:gemma3:4b 명시 추가

실측097 결과

Pipeline 완주: CEO→CPO→CTO→5 Leaders→8 Workers→R02×13→Pipeline complete
SCRAM 0회, IR validation 실패 0회
Bugfix latent: enum-synonym 매핑은 설치되어 있으나 이번 Gemma 실행에서 "blocked" 직접 출력 → 발동 없음. 방어선 자체는 유효
신규 G110: no-op Worker 패턴 — 모든 워커가 status=blocked + files=0 + tokens=0 출력. 구조 관통 vs 실질 deliverable gap
6인 감사 평균 4.00

산출물

docs/realtest/실측097-gemma.md — cycle 5 검증 (PASS structural + caveat)
docs/bugfix/096-cycle5-enum-semantic-mapping.md — cycle 5 Bugfix Protocol
server/src/pipeline/output-schemas.ts — x-synonyms 선언
server/src/pipeline/adapter.ts — enum-synonym coerce
server/.env — DIAMOND_MODEL 명시

다음 차원 (cycle 6 후보)

G110 no-op worker 방지: status=blocked + errors=[] reject, R04 연속 no-op 상한, 또는 Scaffolder skill fallback
측정 축 전환: "깊이(stage 진전)" → "실질(files/tokens 산출물)"

[2026-04-20] cycle 5 착수 — G109 enum semantic drift (WHY)

대상: G109 — Worker status="completed" vs schema enum [success, failure, partial, blocked] 불일치로 SCRAM (실측096).

방향: schema 선언형 x-synonyms + boundary 매핑. 하드코딩 대신 schema 선언부에서 매핑 범위를 명시적으로 허가.

채택 방안: B (docs/bugfix/096-cycle5-enum-semantic-mapping.md) — 4척도 전량 통과.

원칙:

cycle 3(type)/4(existence) 와 대칭 → cycle 5(semantic) 로 robustness 3축 완성
미지의 synonym 은 여전히 throw — 정직한 실패 유지
로그: [IR:enum-synonym] prefix

[2026-04-20] 4-Cycle Gemma 벤치마크 완주 — 실측096 (FAIL@Worker) + cycle 4 Bugfix 확증

총결: 4 cycle 자율 실행 완료. 실패 지점이 매 cycle 마다 +1 stage 깊어짐: 워커blocking → CEO → CTO → Worker.

cycle 4 Bugfix (docs/bugfix/095-cycle4-missing-field-defaults.md)

대상: G108 (CLevel orders: required field missing)
방안 B 채택: coerceToSchema 에 missing-required-array → [] defaulting + [IR:missing-array] warning
구현: server/src/pipeline/adapter.ts:coerceToSchema 확장

실측096 결과 (cycle 4 Bugfix 검증)

Pipeline 4 stage 깊이 도달: CEO(61s) → CTO(100s) → 3 Leaders(39~41s each) → Worker(15s)
소요 330.3s, Ollama 호출 7회
신규 G109: Worker status="completed" 출력 — schema enum [success, failure, partial, blocked] 불일치 (enum semantic drift)
6인 감사 평균 4.33 (역대 최고)

산출물

docs/realtest/실측095-gemma.md — cycle 4 검증 (CTO FAIL)
docs/realtest/실측096-gemma.md — cycle 4 Bugfix 적용 후 (Worker FAIL)
docs/realtest/4cycle-benchmark-2026-04-20.md — 4-cycle 종합 벤치마크
docs/bugfix/095-cycle4-missing-field-defaults.md — cycle 4 Bugfix Protocol
server/src/pipeline/adapter.ts — missing-array defaulting 추가

결정된 엔지니어링 원칙 (4 cycle 누적)

구조 > 프롬프트 (choke point)
Boundary layer 확장 (type → existence → enum 순서)
Strict schema 유지 + 투명 교정
정직한 실패 원칙 (coerce 불가능하면 throw)
[IR:*] 경고 로그 필수

남은 과제 (미해결)

G109 enum drift — cycle 5 후보 (회장 결정 대기)
자율3축 ①②④ FAIL 잔존 (CLevel 시그널 부재 — G105)

[2026-04-20] cycle 4 검증 — 실측095 (FAIL@CTO) + cycle 2+3 Bugfix 효과 확증

배경: 실측094는 스테일 서버 프로세스(모듈 캐시)로 cycle 3 coerce 미적용 상태에서 실행 → 재현 시도. 서버 fresh restart 후 실측095 재측정.

결과: 조기 실패 (CTO 단계) — CEO는 cycle 2+3 Bugfix 덕에 통과, CTO 응답 IR 검증 fail(orders: required field missing) → SCRAM.

CEO 응답 72초 (3,089자) → directive 발급 성공 (no-spec-refusal 효과 ✅)
CTO 응답 92초 (4,217자) → orders 배열 미출력 → validation fail
Pipeline success=false, workers=0, elapsed=164.9s
소요 +152% vs 093 (65s→165s) — 파이프라인이 CTO 단계까지 진입했다는 증거

확증된 cycle Bugfix

cycle 2 (no-spec-refusal): CEO가 refusal 없이 issue_directive 수행 ✅
cycle 3 (IR coercion): CEO fireProposal 타입 통과(coerce 미발동 — Gemma 이번엔 string 출력) ✅
둘 다 cycle 4의 FAIL 지점이 CTO 이후로 이동 = 구조적 전진

신규 발견 (G108)

Gemma 4B가 CLevel schema의 required array field (orders)를 완전히 생략
G107(type drift)과 다른 카테고리 — missing required field. coerce 불가(없는 걸 만들 수 없음)
근본: 약한 모델이 JSON array wrapper를 떨어뜨리고 top-level object만 출력하는 패턴

[2026-04-20] cycle 3 완료 — 실측093 (FAIL) + IR coercion boundary 추가

결과: 조기 실패 — CEO 응답 65초 후 IR 검증 fail (fireProposal.targetCLevel/reason: expected string, got object) → SCRAM.

Pipeline success=false, workers=0, elapsed=65.4s
Skill 엔진은 정상 로드 (3 skills) — cycle 2 Bugfix 효과는 미검증 (워커 단계 미도달)

신규 발견 (G107)

Gemma 4B가 nested object 를 stringfield 에 출력 → IR strict validator 가 SCRAM
근본: 약한 LLM 의 예측 가능한 schema drift 를 orchestrator가 흡수하지 못함

cycle 3 Bugfix (docs/bugfix/093-cycle3-ir-coercion.md)

5-Whys → 약한 모델 drift 흡수하는 boundary layer 부재
방안 채택: C — server/src/pipeline/adapter.ts:validateIR에 coercion 패스 추가
object/array → string(JSON.stringify), string → number/boolean 자동 변환 + [IR:coerce] warning log
4척도 전량 통과 (타협x/양보x/근본o/증상완화배제)

산출물 (cycle 3)

server/src/pipeline/adapter.ts — validateIR + coerceToSchema 추가
docs/realtest/실측093-gemma.md — 보고서 (조기 실패 상세)
docs/bugfix/093-cycle3-ir-coercion.md — Bugfix Protocol

[2026-04-20] cycle 3 개시 — 실측093

의도: cycle 2 Bugfix (no-spec-refusal + reasonable-defaults 확장) 효과 검증. 기대:

G106 (Missing details 블로킹) = 0 또는 극소수
Worker blocked 25 → 한 자릿수 기대
자율3축 ①②④ 여전히 FAIL (G105 대상, cycle 3 부수 관찰)

가설:

H1: blocking 25 → <5 (no-spec-refusal 원칙이 행동 자체 금지)
H2: 신규 블로킹 패턴 0건 또는 전혀 다른 영역에서만
H3: 자율3축 ①② 여전히 FAIL

[2026-04-20] cycle 2 완료 — 실측092 결과 + no-spec-refusal Skill 추가

의도: cycle 1의 Skill 엔진 (scope-disambiguation + reasonable-defaults) 주입 상태에서 실측092 재현. 결과 요약:

Pipeline success: false → true 전환 ✅
소요시간: -51% (804s → 391s)
고유 거절 패턴: -87.5% (8종 → 1종)
총 블로킹: -69% (81 → 25)
6인감사 평균: 3.5 → 4.0

가설 검증:

H1 (scope-disambiguation → G100/G102 전멸) = PASS ✅
H2 (reasonable-defaults → G101/G103 전멸) = PASS ✅
H3 (자율3축 ①② FAIL 잔존) = 확인 ✅ (cycle 3 대상)

cycle 2 신규 발견

G106: worker가 streaming-specific spec 없을 때 "Missing details" 블로킹 25회 — defaults 테이블 coverage 부족.

cycle 2 Bugfix 채택 (docs/bugfix/092-cycle2-no-spec-refusal.md)

5-Whys 근본: "spec 부족을 blocking 사유로 쓰는 행동 학습" — 도메인 catch-up 으로는 영구 미해결.
방안 채택: C — 신규 P0 Skill no-spec-refusal + reasonable-defaults 커버리지 확장 (streaming retry/auth refresh/DRM/logging/rate limit/pagination/timezone).
4척도 전량 통과 (타협x/양보x/근본o/증상완화배제).

산출물 (cycle 2)

server/src/skills/rules/no-spec-refusal.md — 신규 P0 Skill
server/src/skills/rules/reasonable-defaults.md — defaults 테이블 10→20개 항목 확장
docs/realtest/실측092-gemma.md — form-template 기반 보고서 (부록 A 에러 종합표 포함)
docs/bugfix/092-cycle2-no-spec-refusal.md — Bugfix Protocol 기록

[2026-04-20] Gemma 4-cycle 체인 — cycle 2 개시 (실측092)

의도: cycle 1의 Skill 엔진 (scope-disambiguation + reasonable-defaults) 주입 상태에서 실측092 재현. 기대: Worker blocked 81회 → scope/defaults 거절은 주입 Rule로 차단되어야 함. 검증 가설:

H1: G100/G102 (scope 혼동) = 0회 또는 현저히 감소
H2: G101/G103 (industry-standard defaults 거절) = 0회 또는 감소
H3: 자율3축 ①② 여전히 FAIL/PARTIAL (Council post 0건) → cycle 3에서 해결 예정

cycle 2 Bugfix 예상 대상: 남은 5대 패턴 중 상위 2개 (P1 tier: tool-less-improvisation, code-first-not-exec).

[2026-04-20] Skill Engine (cycle 1 bugfix) + Gemma 4회 실측 사이클 개시

배경: 회장 미션 = [실측 → P-0~P-6 → Bugfix Protocol] × 4회 Gemma 체인. 사이클 1 결과:

실측091 완료 (elapsed=804.6s, progress=22%, Retry exhausted=81, escalation=10, 비용=0원).
실패 8대 패턴 추출 → docs/strategy/library-strategy.md 신규 (실패→Skill 역산).
Bugfix Protocol (5-Whys + Diamond 4방안 + 4척도) → 방안 D (choke point Skill 엔진) 채택.

산출물 (cycle 1)

server/src/skills/ 신규 — index.ts / skill-loader.ts / skill-matcher.ts + rules/*.md 2개 (scope-disambiguation, reasonable-defaults)
server/src/orchestrator/llm.ts:1537~ — callAgent choke point pre-hook (injectSkills)
docs/bugfix/091-cycle1-skill-engine.md — Bugfix Protocol 기록
docs/realtest/실측091-gemma.md — 보고서 재작성 (form-template 기반 + 에러 종합표)
docs/strategy/library-strategy.md — Skills 역산 전략 초안

회귀 의심 (실측091)

자율3축 ①② FAIL/PARTIAL — Gemma CLevel Council post 0건 (G105 후보, 092~에서 관찰)

원칙 적용

근본+즉시 (feedback_root_cause_no_phases.md) — Phase 분할 없이 choke point 설계
구조 우선 (feedback_structure_over_prompt.md) — 프롬프트 주입이 아닌 코드 플로우 강제 경유점
Generate-Verify — Skill 주입은 generate 측 교정, Verify(BuildValidator)는 불변

[2026-04-20] LLM Adapter Layer ADR + gemma3:4b 단독 실증 전략 확정

결정: 어댑터 계층 도입 (방안 A). 인터페이스 3-way (Claude/Codex/Ollama), 구현 2-way (Codex 스텁). 배경: 회장이 "gemma3:4b 단독으로 돌려 Skills 역산" 전략 확정. spawn(provider='claude') 3곳 하드코딩(llm.ts:909/1129/1576)으로 물리적 불가 → orchestrator 벤더 중립화 필요.

프로토콜 — Bugfix Protocol 적용

5-Whys: 기술 문제(spawn 하드코딩)가 아니라 전략 결정 공백(실증으로 Skills 역산한다는 전략이 없었음)이 근본. 회장이 확정한 순간 근본 해결, 본 ADR은 실행 수단 선택.
다이아몬드 4방안: A(어댑터), B(환경변수 분기), C(fork 실증), D(팩토리 함수).
4척도 검증: A만 전부 통과. B=증상완화, C=두 번 일함, D=Codex tool-use 규약 흡수 불가.
회장 파라미터 3개: 실증 10회+ / Codex 2주 뒤 결제 / 수직전문 3개월 내 본격화 → A 정당화.

산출물

docs/spec/adr-llm-adapter.md — ADR v3 본문 (Bugfix Protocol 전 과정 기록)
docs/plan/gemma-only-realtest.md — 실측091 계획 (지표 6개, 반복 10회 로드맵)
docs/todolist/active.md — 8단계 태스크 추가
server/src/orchestrator/llm.ts — resolveTransport + stripModelPrefix 도입, 3개 진입점(callAgent/callClaude/callDirectorStateless) 입구 전송 분기, callOllamaAgent에 modelOverride 파라미터 추가
server/src/pipeline/adapters/codex-cli.ts — 신규 CodexCLIAdapter 스텁 (throw)
server/src/pipeline/pipeline-bridge.ts — codex-cli 등록 추가
(예정) docs/strategy/library-strategy.md — 실측091 이후 실패→Skills 매핑 초안

tier별 혼용 지원 (회장 추가 요구)

CLEVEL_MODEL=opus, LEADER_MODEL=codex:gpt-5-codex, WORKER_MODEL=ollama:gemma3:4b 와 같이 tier별 다른 어댑터 혼용 가능. 기존 getModelForRole/getModelForTier의 tier 해석 + 신규 resolveTransport 의 prefix 분기가 한 choke point에서 자동 라우팅.

v3 재설계 트리거 (v2 → v3)

server/src/pipeline/adapters/ 기존 존재 발견 → orchestrator/adapters/ 신규 생성 폐기 (중복 회피)
회장 추가 요구 "C레벨=opus, 간부=codex, 워커=gemma" → tier 혼용 요구사항 흡수

교훈

ADR 초안(v1)이 5-Whys를 Why3에서 중단 + 확증편향(A 먼저 세워놓고 나머지 깎아내림) + 4척도 명시적 검증 누락으로 폐기. 회장 지시 "bugfix프로토콜과 5whys 적용해서 평가"로 결함 노출 → v2 재작성. 이후 기존 adapter 인프라 발견 + tier 혼용 추가 요구로 v3 재설계. 설계 문서도 중간에 사실 관계가 바뀌면 즉시 반영.

[2026-04-19] 레거시 파이프라인 완전 제거 → C4I 전환

결정: index.ts processMessage() 내 레거시 파이프라인(~1200줄)을 executeC4IPipeline() 1줄 호출로 교체. 배경: C4I 파이프라인 19파일 완성(실측081~086 검증). 레거시 코드가 index.ts에 남아있어 C4I 전환 불가 상태 지속. 파이프라인 연결이 커밋되지 않아 rsync 덮어쓰기로 유실된 것 확인. 결과:

index.ts: 2331줄 → 961줄 (59% 감소). 레거시 파이프라인 실행부 제거, executeC4IPipeline() 1줄 교체. 인프라(H1~H5, I20, boot, work queue) 유지.
utility 함수 5개 삭제: compressOpinionForConsensus, extractCEOSummary, buildFactReport, detectTechConflicts, detectDuplicateTypes.
import 12개 정리: cfo-pipeline, debate, debate-filter, debate-consigliere, sections, intent-quality(부분), auto-fix, clevel-director, leader-escalation(부분), budget-signal, phase-detector(부분), parser.
orchestrator/ dead 파일 14개 삭제: diamond-debate, diamond-analyzer, diamond-hybrid, diamond-filter, diamond-dag, viewholder-pool, clevel-director, budget-signal, cfo-pipeline, auto-fix, security-handler, tier-routing, parser, test-pipeline.
tsc --noEmit 0에러.

[2026-04-17] 1단계 재설계 — CEO 분석 경로 choke point 배선

WHY (근본 원인 2가지)

index.ts:1054 게이트 if (dbCLevels.length === 0): DB에 C레벨 seed 잔재가 있으면 CEO 분석 자체 스킵. 077에서 1차 aborted run의 CTO/COO 잔재 → 조건 항상 false → A01-A09 전부 0건.
C레벨 선택 이원화: getActiveCLevels(phase) 하드코딩(무조건 CTO+COO)이 SpecIssuer/Director에 직접 공급. CEO의 동적 hire 결과와 무관 — 하드코딩이 있는 한 CEO 분석의 존재 의미 없음.
CEO 분석이 비차단 비동기 (.then(...))로 실행 — hire 완료 전에 SpecIssuer/Director가 먼저 시작.

수정 방향 (회장 원칙: "프롬프트 믿지 말고 구조화")

CEO 분석을 processMessage 의 첫 번째 동기 단계로 올림 (await)
getActiveCLevels(phase) 하드코딩 → CEO hire 후 DB 기반 activeCLevels 로 전환
dbCLevels.length === 0 게이트 제거 — CEO가 항상 분석
분리 실측: BOOT → CEO 분석(A01-A03) 마커 확인까지만
4단계까지 sonnet만 사용 (회장 지시)

WHAT (실측078a 결과)

A01→A02→A05→LH06→A03 전부 발화 성공. 077에서 0건이었던 CEO hire 경로가 choke point 배선으로 동작.

수정 코드:

index.ts:1022-1063 — CEO 분석을 .then() 비동기에서 await 동기 첫 단계로 변경 + dbCLevels.length === 0 게이트 제거 + activeCLevels를 DB-first/registry-fallback 으로 전환 + C_LEVEL_REGISTRY import 추가.
leader-hire.ts:52 — leader ID == C-level ID 충돌 가드 추가. sections.ts:52 의 architecture.leader='cto' 가 CTO agent tier를 clevel → leader 로 덮어쓰는 X04 버그 차단.

발견 + 해결된 이슈:

X04 3건 (parent_clevel_id=cto does not reference a tier=clevel agent): leader-hire.ts 가 CTO와 동일 ID 로 leader upsert → CTO agent의 tier 덮어씀. leader ID 충돌 가드로 근본 해결.
CEO notice → processMessage 재트리거 루프: CEO 가 chairman 채널에 notice 게시 → agent_id='ceo' 가 필터 통과 → 재분석. 자기 소멸형 (기존 C레벨 전부 고용 후 proposals=0 → 자연 종료). 5회 반복 후 6명(CTO/COO/CPO/CISO/CFO/CMO) 전원 고용. 향후 최적화 대상 (불필요한 API 호출 5회).

078a 마커 집계:

A01: 5회 (5차 반복)
A02: 4회 (1차: CTO/COO/CPO, 2차: CISO, 3차: CFO, 4차: CMO)
A03: 4회
A05: 6회 (C-level 6명)
LH06: 7회
X04: 3회 (leader-hire CTO 충돌 — 핫픽스 완료, 재실측 대기)

[2026-04-17] 실측077 결과 — S1/S4 런타임 미통합 확인 (dead code)

WHY

실측077 회귀 검증 목적: S1(CEO 자율 hire + revoke) + S4(dispatcher.ts 3홉 강제 라우팅) 구현이 배포 후 실제 파이프라인에서 동작하는지 확증.
결과: iOS retry 2/3 에서 ios_dev_1 480초 timeout → 워크플로우 실패 (code=143 SIGTERM). 총 4,098원, Sonnet 4.6.

WHAT (관측 사실)

S1 dead code 확증: A01-A03 (analyzeProjectScope, proposeCLevelHiring, clevel_hired) 0건. LH01-LH06 (leader hire 라이프사이클) 0건. chairman_approvals INSERT 0건. ceo-agent.ts::analyzeProjectAndProposeHires() 는 추가되었으나 server/src/index.ts CEO 오케스트레이션 플로우가 호출하지 않음 — CLevelDirector 가 leaders: none, workers: 6명 상태로 그대로 진입.
S4 dead code 확증: D03 6회 발화했으나 전부 기존 tier-routing.ts WARN 모드 출력 ({"from":"director_merged","to":"ios_dev_1","reason":"clevel can only delegate to [leader], got worker"} passthrough). 새 dispatcher.ts::routeTask() 는 callAgentsParallel / delegateToLeader 호출부에 배선되지 않음.
X 시리즈 재발 검증: X02 (auto_approved status check) 0건 — 단, 하이어 경로 자체 미진입으로 미검증. X04 (parent_clevel_id column not found) 0건 — migration 067 prod DB 수동 적용으로 근본 차단 확인. H4 (CEO 자기 notice 로 취소) 0건 — isHumanChairmanDirective 가드 정상 동작.
자율 3축 미검증: G76 권한(CEO 자율 해고/승진) 0건, G82 시그널(Director 성과 알림) 0건 — 전부 S1/S4 통합 미완으로 기회 없음. G79 학습은 회장 메시지 0건으로 N/A.
마이그레이션 누수: prod .env 에 DATABASE_URL/SUPABASE_DB_PASSWORD 없음 → migrate.ts REST 폴백 → migration_history 테이블 부재 → 마이그레이션 자동 적용 완전 skip. 8건 pending 파일 목록만 로그 출력. S1/S4 마이그레이션은 OpenSource 쪽에서 npx supabase db push 로 수동 적용된 상태.
문서: docs/realtest/실측077.md (전체 타임라인 + S1/S4 dead code 분석 + X 시리즈 재발 검증 + 자율 3축 + 다음 액션 5건), docs/ISSUES.md S1/S4 행을 ⚠️ 런타임 미통합으로 전환, docs/todolist/active.md T0 S1/S4 동일 업데이트.

다음 턴 우선 액션

S1 통합: index.ts CEO 프로젝트 수신 분기에 analyzeProjectAndProposeHires() 호출 삽입.
S4 통합: callAgentsParallel 진입점에서 dispatcher.ts::routeTask() 경유 + tier-routing.ts WARN 분기 흡수.
Seed 정리: residual agents 정리 로직 또는 --fresh-seed 플래그.
DATABASE_URL 배포: prod .env 에 추가 또는 SUPABASE_DB_PASSWORD 로 자동 마이그레이션 복원.
실측078 재검증.

[2026-04-16] 실측077 모델 전환 — Opus → Sonnet (토큰 절약)

WHY

회장 지시: "실측때 opus말고 sonnet으로해봐 지금 토큰딸린다".
현재 prod 환경: LLM_MODEL=opus + ceo-agent.ts:21 의 CEO_MODEL 기본값이 claude-opus-4-6 → CEO/C-level/Leader 전부 opus 로 동작 중.
실측076 비용 4,715원 (opus 기준). 실측077 은 S1+S4 회귀 검증이 목적이며, sonnet 으로도 CTO hire·leader 체이닝·D03 분기 검증 가능.
참고: 메모리의 "Sonnet 소진 시 opus 전환" 규칙은 역방향. 이번 회차는 opus 소진 추세로 sonnet 복귀.

WHAT

server/.env (prod): LLM_MODEL=opus → LLM_MODEL=sonnet + CEO_MODEL=claude-sonnet-4-6 명시 (ceo-agent.ts 하드 기본값 opus 오버라이드).
tier 매트릭스 (sonnet 회차):
CEO: sonnet (CEO_MODEL 명시)
C-level: sonnet (llm.ts:23 CLEVEL_MODEL || LLM_MODEL)
Leader: sonnet (leader-hire.ts:15 LEADER_MODEL 기본값)
Worker: haiku (llm.ts:25 기본값 유지)
OpenSource 저장소 .env 와 .env.example 은 변경 없음(개발 기본값 sonnet 유지 중). ceo-agent.ts 하드 기본값은 opus 그대로(프로덕션 정식 운용 시 복귀 용이).

[2026-04-16] T0 크리티컬 — S1+S4 구현 완료 (실측077 회귀 대기)

완료 결과

공백	실제 수정	회귀 가드
S1 CEO 동적 hire 경로 사망	`ceo-agent.ts` `proposeCLevelHiring()` 이 `chairman_approvals.status='auto_approved'` 감사기록 + `hireCLevel()` + `hireLeadersForCLevels()` 체이닝. `index.ts` chairman_approvals Realtime 리스너는 `status='revoked'` → `revokeAgent()` 로 리매핑. 대시보드 `POST /api/agents/:id/revoke` + Agents 패널 revoke 버튼(CEO 서버/UI 이중 차단).	test-pipeline [8] 4건 — approval wait 제거 / revoked 경로 / auto_approved 즉시 기록 / revokeAgent export
S4 LEADER tier 3층 부재	`migration 067_leader_tier.sql` — `parent_clevel_id REFERENCES agents(id)` + `uniq_agents_role_project_active` 부분 UNIQUE + `enforce_leader_parent()` 트리거(tier='leader' 는 parent tier='clevel' 필수). `dispatcher.ts` 신설 — `routeDelegate()` 가 DB 리더 row 존재 여부로 D03(3홉)/D04(2홉) 자동 분기. `leader-hire.ts` upsert 에 `parent_clevel_id: section.cLevel` 주입.	test-pipeline [9] 4건 — backend_dev/frontend_dev/unknown 매핑 + leader-hire parent_clevel_id 주입 확인

핵심 설계 결정

승인 대기 → revoke 권한 전환: 회장 승인 클릭 누락으로 인한 hire chain 사망을 구조적으로 제거. CEO 는 CTO 등 C-레벨 + 리더를 자율 고용, 회장은 언제든 revoke. CEO 자신은 revoke 불가(tier CHECK 과 protect_ceo_active 트리거, UI 에서도 차단).
DB state as policy: dispatcher 는 외재 정책 파일 없이 DB 의 agents row 상태만으로 3홉/2홉 분기. 정책과 상태의 sync 부담 제로.
4홉 체인 가능화: S4 로 CLevel→Leader→Worker 경로가 실제 생성되어야 S5(REPORT_UP 4홉) 관측이 의미 있음. 순서가 맞음.

Typecheck & Test

npx tsc --noEmit — server + dashboard 양쪽 에러 0건.
test-pipeline 총 68건 PASS (기존 60 + 신규 S1/S4 가드 8건).
OpenSource → /Users/cavss/Desktop/bigbossos/ prod rsync 완료 (migration 067, ceo-agent.ts, dispatcher.ts, leader-hire.ts, index.ts, test-pipeline.ts, dashboard route.ts, dashboard page.tsx).

남은 검증

실측077 필요: 회장 메시지 → CEO 가 자율 C-레벨 고용 → 리더 체이닝 → DELEGATE 3홉 로그 확인. [Lifecycle] A02/A03/LH02/LH03/LH06/D03 마커 자연 발생 여부 관찰.

다음 (S2 → S5 → S3 폭포수)

S1+S4 로 구조 뼈대 완성 → S2(ViewHolder 실사용) → S5(Council reflectLoop 실 INSERT + 4홉 마커) → S3(Diamond 토론 훅). 각 단계 다이아몬드 토론으로 100% 근본안 검증 후 착수.

[2026-04-16] T0 크리티컬 착수 — S1+S4 근본 해결 진행중

WHY (회장 지시 — 100% 근본)

실측076 갭 분석으로 설계 100 중 핵심 경로 5건 사망 확증 (S1~S5). 실측076 PASS 판정은 레거시 파이프라인 검증에 한정. 4층 아키텍처(CEO→CLevel→Leader→Worker) 중 Leader tier 전체 🚧, CEO 동적 hire A03~A08 마커 0건.

회장 지시: 증상치료 필요 없음, 100% 근본 원인 해결. 다이아몬드 토론으로 수정안(90%) 의 증상 잔재 4개 제거 — 승인 대기 특례(자율성 파괴) · 외재 정책 파일(sync 부담) · "A04/A07만 구현, 나머지 S5 통합"(뒤로 미룸) · 마커 주입(결과와 원인 혼동). 100% 근본안 합의.

100% 근본안 (Final)

설계 공백	근본 해결안
S1 CEO 동적 C-레벨 고용	승인 대기 폐기 → CTO `[CLEVEL_PROPOSAL]` JSON 자율 hire + 회장 `revoke` 권한. A-phase 각각 실제 코드 경로 1:1 매핑
S4 LEADER tier 부재	migration 067 `tier` CHECK 확장 + `(role, project_id)` UNIQUE. tier-aware dispatcher — DB 상태가 정책(외재 파일 없음). `_lead` 감지 시 `hireLeader` 자동
(공통)	Race 방어 `ON CONFLICT DO NOTHING`. 롤백 SQL 동봉. schema 실검증 선행 (`agents.tier` 타입 조회)

작업 순서

① WHY 문서화 (ISSUES.md S-시리즈 + CHANGELOG.md 본 섹션) ← 진행중
② DB schema 실조사 — `agents.tier` 현재 타입/제약
③ migration 067_leader_tier.sql (CHECK 확장 + UNIQUE + 롤백)
④ ceo-agent.ts — proposeCLevelHiring 확장 (CTO 자율 hire) + hireLeader + revokeAgent
⑤ dispatcher.ts — routeDelegate 신설 (DB 기반 자동 분기)
⑥ dashboard — /api/agents/:id/revoke + revoke 버튼
⑦ typecheck + test-pipeline 회귀 가드 2건 + prod rsync
⑧ WHAT 문서화 (실측077 회귀 검증 대기)

S2/S3/S5 는 S1+S4 완료 후 폭포수 순차. 각각 다이아몬드 토론 거쳐 100% 근본안 수립.

[2026-04-16] 실측076 — G83/G84/G85/G55/G81-R 회귀 PASS + G60 CLOSED + 신규 G86/G87/G88

회장 메시지 INSERT(id=28895, 21:51:13) → [CLI] 응답 완료(22:26:54). 총 35분 41초, 비용 4,715원, DQ=1.

회귀 검증 결과 (배치 수정 모두 PASS)

이슈	판정 근거
G81-R 워커 권한 차단	1차+2차+재위임 파이프라인 모두 `[Parallel] 완료 — 성공: 6/6 (또는 2/2)`. bypassPermissions 전환 후 hang 재현 0건
G83 iOS 스캐폴드 중복	2차 H2 큐 재처리 시 22:09:02 "병렬 스캐폴딩 완료" 에서 신규 iOS 디렉토리 생성 0건, 기존 `ios/StreamApp/` 유지
G84 2차 메시지 메타 유실	22:10:02 iOS 워커가 `.../StreamApp/Network/NetworkError.swift` 경로에 작성 (reconcileProjectMetadata 디스크 복원 정상). 074 의 `App/` 경로 회귀 제거
G85 Simulator 팝업	retry 루프 진입 후에도 GUI 팝업 비정상 반복 없음
G55 Phase B 타임아웃	wbs/gantt/raci/risk/status/sla/adr/tech-debt 전 체인 timeout 0건
G60 CFBundleVersion 누락	R24-B 정적 검증 PASS, 번들 실패 0건 → 정식 CLOSED

자율복구 관찰

1차 파이프라인에서 iOS retry 루프 중 ios_dev_1 code=143 (SIGTERM) 으로 워크플로우 실패(22:08:25). 그러나 CEO 자기호출 메시지가 H2 큐에 적재돼 있어 22:08:26 자동 재처리 시작 → 2차 파이프라인 완주. 회장 재전송 없이 [CLI] 응답 완료 달성. 이 구제 경로는 현재 우연적이며 G86 수정으로 명시적 경로로 승격 필요.

신규 이슈

G86 (HIGH) — iOS retry 워커 SIGTERM 에 대한 명시적 구제 분기 부재. 현재는 H2 큐 자동복구가 우연히 커버.
G87 (HIGH) — iOS 워커가 APIService.swift 를 Network/ + Services/ 두 경로에 중복 생성 → Swift filename used twice 에러. systemRules/스캐폴드 네이밍 가이드 부재.
G88 (HIGH) — BuildValidator 파서 false negative: Android Kotlin daemon terminated·iOS filename used twice 를 "에러 0건" 으로 감지. G57 수정 이후 남아있는 감지 공백.

[2026-04-16] G83/G84/G85/G55 배치 해결 + G60 오진 확인

실측075 hang (G81-R) 해결 후, 실측076 회귀 검증 전 남은 블로커를 한 번에 제거.

G83 — Scaffold iOS 멱등성 (`scaffolding-agent.ts:63~`)

WHY: H2 큐가 2차 chairman 메시지(C레벨 고용 확인 등)를 플러시 → processMessage 재진입 → 2차 메시지는 "프로젝트명:/패키지:" 토큰 부재 → parseCEOMessage 기본값 App 폴백 → isAlreadyScaffolded('ios', {name:'App'}) 이 ios/App/...pbxproj 부재 확인 → 2차 ios/App/ 중복 생성. 실측074 로그 06:35:59 🏗 ios 스캐폴딩 시작: App 으로 확증.

CODE: isAlreadyScaffolded 의 iOS 분기를 name 매칭 대신 ios/<any>/<any>.xcodeproj/project.pbxproj 존재 검사로 일반화. name 불일치 재스캐폴드 불가능.

G84 — parseCEOMessage 2차 메시지 기본값 폴백 (`parser.ts`, `index.ts:50,1026,1338`)

WHY: 075 리포트의 "Scaffold Android 패키지 하드코딩" 가설은 오진. 실제로 Scaffold 는 opts.pkg 를 정확히 사용. 진짜 원인은 H2 큐 플러시된 2차 CEO 메시지에 프로젝트 토큰 부재 → parseCEOMessage 기본값 App/com.example.app 폴백 → downstream 모든 프롬프트/Scaffold/Spec 이 디스크 실제 상태(StreamApp/com.jupond.streamapp)와 불일치. 실측074 07:38:49 [R17] 오판 보정: Android 패키지명 불일치 로그로 확증.

CODE:

parser.ts — readExistingProjectMetadata(projectDir) 추가 (ios/<Name>/pbxproj 에서 실제 name + PRODUCT_BUNDLE_IDENTIFIER 추출) + reconcileProjectMetadata(parsed, projectDir) 추가 (parsed 가 기본값이면 디스크 복구값으로 override).
index.ts:50 reconcile import 추가.
index.ts:1026 메인 parse 지점 + index.ts:1338 scaffold 직전 parse 지점 모두 reconcileProjectMetadata 로 래핑.

G85 — Simulator.app 3회 팝업 (`project-validator.ts:656~`)

WHY: G72 의 open -a Simulator 호출이 simulatorRunIOS() 내부에 있어, G61 iOS retry while-loop (IOS_MAX_RETRIES=3) 가 돌 때마다 1회씩 GUI 전면화 → 회장 작업 창 탈취 3회.

CODE: execFileSync('pgrep', ['-f', 'Simulator.app']) 가드 추가. exit 0(실행 중) 이면 open 생략, exit 1(미실행) 이면 기존대로 열기. retry 3회 → 팝업 1회.

G55 — Phase B gantt/raci timeout (`spec-issuer.ts:166`)

WHY: 실측074 로그: ⚠️ CTO Phase B [gantt] 실패 (계속): Error: spec-issuer LLM timeout (300초). opus 모델 기준 gantt 생성이 5분(기본) 초과. sonnet 주간 쿼터 소진 상태라 opus 가 기본이 됐기 때문 (cf. MEMORY project_api_quota.md).

CODE: PHASE_B_TIMEOUT_MS 기본값 5 60 1000 → 10 60 1000. env SPEC_PHASE_B_TIMEOUT_MS 로 계속 조정 가능. Phase A 는 5분 유지.

G60 — CFBundleVersion 재발 라벨 오진 확인 (no-op)

WHY: 실측074/075 리포트가 "G60 재발" 이라고 라벨링했지만 074 로그 재검 결과:

R24:Simulator 📱 StreamApp.app | bundle: com.jupond.streamapp (bundle ID 추출 성공)
번들 정적 검증 실패 로그 0건 (R24-B 정적 게이트 PASS)
앱 실행됨 (PID: 95950) → 5초 후 🔴 앱 크래시 감지 (런타임 프로세스 소멸)

즉 CFBundleVersion 은 정상 주입됐고 (pbxproj 733-734/755-756 에 CURRENT_PROJECT_VERSION=1 / MARKETING_VERSION=1.0 이미 존재), 실제 크래시는 런타임 (앱 실행 후 5초 내 크래시). CFBundleVersion 경로와 무관. 074/075 의 iOS 3회 retry 실패는 별도의 런타임 크래시 클래스(신규 G86 후보로 관찰). G60 자체는 이번 배치에서 코드 수정 없음 — 실측076 에서 재발 없으면 CLOSED.

검증

npx tsc --noEmit (server) → 에러 0건.
실측076 대기 — 5축(G81-R + G83 + G84 + G85 + G55) 동시 회귀 검증.

[2026-04-16] G81-R 근본 해결 — `--permission-mode dontAsk` → `bypassPermissions`

WHY: 실측075 hang 의 직접 원인 (워커 6명 전원 Write/Bash 도구 "don't ask mode" 묵시 차단, 산출물 0).

근본 원인 확정 (로컬 재현 3회):

--permission-mode dontAsk 의 실제 semantics = "묻지 말고 거부" (prompt 없이 silently deny). -p 비대화 세션에서는 prompt 응답 경로가 없어 모든 권한 요구 툴 (Write/Edit/Bash) 묵시 차단.
bypassPermissions = "묻지 말고 통과" 가 비대화 에이전트 올바른 값.
부수 검증: bypassPermissions + C-level role → bigboss-role-guard.sh 의 hard-deny 훅은 여전히 작동 → G81 R2 가드(C-level 코드 파일 차단) 의도 손상 없음.
CLI 플래그 이름 직관성 부족이 오해의 기원 — dontAsk(거부) vs bypassPermissions(통과) 를 이름만으로 구분 어려움.

수정 (4곳):

server/src/orchestrator/llm.ts:843 — Director stateless call
server/src/orchestrator/llm.ts:1072 — Director docs call
server/src/orchestrator/llm.ts:1483 — 일반 에이전트(워커 포함) + 재발 방지 주석 추가 (1481줄)
server/src/orchestrator/spec-issuer.ts:179 — SpecIssuer Phase A/B call

검증:

① 단일 워커 spawn dry-run (BIGBOSS_OS_AGENT=1 BIGBOSS_AGENT_ROLE=ios_dev_1 claude -p --permission-mode bypassPermissions --tools 'Read,Write,Edit,Glob,Grep,Bash' "Write tool...") → permission_denials: [], 3.3s, 파일 정상 생성.
② C-level 역할(cto) 로 .ts 파일 Write 시도 → 훅 deny 정상 차단, R2 가드 유지.
③ npx tsc --noEmit 에러 0건.
④ OpenSource → prod rsync 완료.

실측076 회귀 검증 대기. 회귀 성공 시 G76+G82+G79+G81+G77+ViewHolder 자율 3축 통합 PR 검증 목적 달성 가능.

잔여 이슈: G83/G84/G85 (scaffolding 관련) + G60/G55 재발 + R17 — G81-R 블록 해제됐으므로 병행 가능.

[2026-04-16] 실측075 — 회장 강제 종료 (워커 전원 권한 차단 → hang)

WHY: 자율 3축 통합 PR (G76+G82+G79+G81+G77+ViewHolder) + G60/G55/R17 재발 수정이 실제 회귀 차단됐는지 실측 검증 목적.

타임라인 (22분, 20:12→20:34): Scaffold iOS/Android → iOS 빌드 3회 retry 모두 실패 → Evaluator "전 에이전트 실행 실패" 판정 → DELEGATE 재시도 loop hang → 회장 강제 종료.

근본 원인 (관찰): 워커 6명(ios_dev_1/android_dev_1/biz_dev_1/designer_1/db_dev_1/api_dev_1) 전원이 "Bash/Write 도구 차단 (don't ask mode)" 자가 보고. ios/ Swift 0줄, api/ 디렉토리 부재, *.ts 0건. G81 ✅ 처리가 실측에서 재발(G81-R) — 다른 G-건 검증 전면 blocker.

신규/재발 이슈 4건:

G81-R CRITICAL — 워커 Write/Bash 차단 재발. 의심: --permission-mode dontAsk 가 CLI 유효값 아닐 가능성(default/acceptEdits/plan/bypassPermissions). 단일 워커 dry-run 재현 + spawn 명령 실제 값 확인 필요.
G83 HIGH — iOS Scaffold 멱등성 부재. ios/StreamApp/ + ios/App/ 중복 xcodeproj. scaffolding-agent.ts existsSync 가드 + 경로 결정론화.
G84 HIGH — Android Scaffold 패키지 하드코딩. 명세 com.example.app 무시 com.jupond.streamapp 고정. 템플릿 변수화.
G85 MEDIUM — Simulator.app 3회 GUI 팝업. G72 open -a Simulator × G61 iOS retry loop 상호작용. retry 밖 1회 또는 pgrep 가드.

연쇄 재발: G60 (CFBundleVersion 누락 추정 iOS crash 3회 retry) — 074 에 이어 075 에서도 재발 확인.

회장 개입: DELEGATE 재시도 루프가 권한 차단 상태에서 무한 hang → 강제 종료. 자율 3축 검증 목적 판정 유보.

문서화: docs/realtest/실측075.md 인시던트 보고서 작성, docs/ISSUES.md 에 G81-R/G83/G84/G85 등록, docs/todolist/active.md 에 G81 재발 반영 + 즉시 실행 순서에 ⓪ G81-R 최우선 진단 단계 추가.

[2026-04-16] 실측074 — P1+P2 회귀 PASS + G60/G55/R17 재발 관찰

WHY: 커밋 61de48f (P1+P2) 가 실측073 의 35분 hang 을 근본 차단했는지 실측 검증.

P1+P2 검증 결과 — ✅ PASS:

부팅 마커 3종 전원 확인: (fetch timeout 30000ms) / 메시지 구독 시작 (폴링 주 + Realtime 부) / [Watchdog] 시작 — timeout 1200000ms, check 60000ms
hang 마커 전 구간 0건 (93분 관찰): Watchdog 자동 리셋 0, setImmediate 지연 0, [H2] ❌ 0
[CLI] 응답 완료 8회 정상 turnover, H2 큐 직접 호출 경로 동작 확인
실측073 35분 hang 증상 완전 소멸

재발 이슈 3건 (P1+P2 무관, 별도 이슈):

G60 재발: iOS 런타임 crash 3회 retry 소진 (06:27~06:31 [R24:Simulator] 🔴 앱 크래시 감지). CHANGELOG 에 G60 pbxproj CFBundleVersion 4줄 추가 가 근본해결로 기록됐으나 실측074 에서 재발 — rsync 된 scaffolding-agent.ts 가 실제 pbxproj 생성 시점에 주입을 빠뜨리는지 재점검 필요.
G55 재발: SpecIssuer 300초 timeout 2건 (CTO Phase B [gantt], COO Phase B [raci]). CHANGELOG 의 PHASE_A/B_TIMEOUT_MS env 5분 확장 은 env override 가 없으면 적용 안 되는 구조일 가능성 — .env 에 값 주입 또는 기본값을 5분으로 코드 고정 필요.
R17 실행 실패 9건 (designer_1×3, db_dev_1×2, api_dev_1×3, ios_dev_1×1). 실측072 흐름 연장선.

비용 특이점:

실측중 CostLog 누적 ~19,000원, test-record 자동 판정 754원 → parser 집계 누락 또는 서버 조기 종료 영향.
LLM_MODEL=opus 설정 (Sonnet 주간 쿼터 소진 대응). 이전 sonnet 기반 실측(071=2,622원) 대비 단가 5배 추정.

회장 개입: 90분 폴링 만료 + 토큰 소모 우려로 A안(조기 종료) 선택. P1+P2 검증 확정 판정, 앱 빌드 완결성 판정 유보.

IMPACT: P1+P2 프로덕션 검증 완료. G60/G55 재발 항목은 ISSUES.md 에 재오픈 처리 예정.

[2026-04-15] P1+P2 — H2 큐 재삽입 무한 pending 근본 해결

WHY: 실측073에서 첫 응답 완료(22:10:38) 후 35분간 hang. 원인: H2 큐 runner 의 두 번째 await getSupabase().from('messages').insert({agent_id:'chairman', ...}) 가 DB에 도달하지 못한 채 Promise 영구 pending (DB에 재삽입된 row 부재 확인). timeout 부재 + DB round-trip 간접 트리거 구조가 fragile.

WHAT:

supabase.ts 이원화 — sbDb (AbortController + 30s fetch timeout) 와 sbRealtime (native fetch, WS 전용) 분리. getSupabase() 는 sbDb 반환 (하위호환). getRealtimeClient() 신규 export. Realtime WS heartbeat 영향 차단.
processMessage 함수 추출 — index.ts subscribeToMessages 람다(1600줄)를 이름 붙은 async function processMessage(msg: Message) 로 추출. 본문 동일. Realtime/H2 두 진입점이 동일 함수 공유.
H2 큐 DB round-trip 제거 — 기존 await insertMessage + await getSupabase().from('messages').insert(chairman) 제거. setImmediate(() => processMessage(synthetic)) 직접 호출. 재귀 스택 차단. 5초 지연 감지 경고 로그.
workflow-watchdog.ts 신규 — 채널별 notifyWatchdog/clearWatchdog. 20분 무활동 시 auto reset + chairman alert + 상세 덤프. WATCHDOG_TIMEOUT_MS env override.
Realtime 구독 5곳 교체 — index.ts agent_changes/client_logs, supabase.ts all_messages, clevel-council.ts council:*, clevel-observer.ts channelKey, llm.ts agent_processes → getRealtimeClient() 사용.
test-pipeline 회귀 가드 2건 신규 — [6] Realtime client 의 .from() 오용 0건, [7] H2 블록 내 chairman DB 재삽입 패턴 제거 검증.

HOW TO VERIFY (실측074 예정):

grep "fetch timeout" /tmp/bigboss_os_testNN.log → 서버 기동 시 timeout ms 로그 확인
grep "\[H2\] ✅ 큐 실행 시작" /tmp/bigboss_os_testNN.log 직후 processMessage 활동 이어짐 (DB 재삽입 흔적 없음)
grep "setImmediate 지연" /tmp/bigboss_os_testNN.log → 경고 없어야 정상
grep "\[Watchdog\]" /tmp/bigboss_os_testNN.log → 정상 종료 시 timeout 로그 없음
npx tsx src/test-pipeline.ts → 60/60 통과

IMPACT: H2 큐 재기동 성공. chairman 연속 요청 시 대기 큐 자연 dequeue. hang 발생해도 20분 후 자동 리셋으로 서버 영구 정지 방지. Supabase insert 전체에 30s hard timeout 내장 → 네트워크 악화 시 영원히 pending 되지 않고 명시적 에러로 reject.

LIBS: 신규 의존성 0. 기존 @supabase/supabase-js 취약점 0건 (npm audit --production). fs/crypto 등 node 내장만 사용.

[2026-04-15] G55/G60/G61/G63/G72/G73/G75/G77 + 실측4축 — 9건 근본 해결

WHY: ① 자율 3축 통합 PR 완료 직후, 회장이 남은 9개 CRITICAL/HIGH 항목 전수 자동화 지시 ("이 항목들만 모두 자동화하는거야"). 각각이 다른 축을 닫음 — G77=시그널, G61/G63=retry/crash, G60=scaffold, G72=가시성, G73/G75=검증, G55=spec timeout, 실측4축=검증 기준.

WHAT:

G77 비용/시간 시그널 주입 — server/src/orchestrator/budget-signal.ts (신규). collectBudgetSnapshot(projectId) → raw_metrics 최근 30분 agent_task 에서 avg duration/cost 집계 + ViewHolder Pool 상태. buildBudgetBlock 프롬프트 생성 (ETA/누적cost/hire 시 예상 증가/Pool busy ≥80% 경고). clevel-director.ts RunCLevelDirectorsOptions.budgetBlock 추가 후 CTO 등 C레벨 프롬프트에 주입. index.ts Phase 1 전에 buildBudgetBlockAsync(currentProjectId) 호출. → CTO 가 hire 제안 시 "무한 hire 위험" 자각 가능.
G55 Phase A1 timeout 파라미터화 — server/src/orchestrator/spec-issuer.ts PHASE_A_TIMEOUT_MS/PHASE_B_TIMEOUT_MS env constants 도입 (기본 5분). 기존 3분 default → 5분 으로 확장. Phase A1/A2 동일 적용. → opus 재시도 케이스 180초 초과 방지.
G60 pbxproj CFBundleVersion 4줄 추가 — scaffolding-agent.ts iOS main target Debug+Release 양쪽에 CURRENT_PROJECT_VERSION=1; + MARKETING_VERSION=1.0; 주입. → GENERATE_INFOPLIST_FILE=YES 가 auto-gen plist CFBundleVersion 을 0/빈값 대신 정상 값으로 채움. R24-B simulator 차단 근본 해결.
G61 iOS retry while-loop — index.ts iOS 빌드 검증 블록을 while (buildErrors.length > 0 && retry < IOS_MAX_RETRIES) 로 재구성. IOS_RETRY_MAX env (기본 3). 매 iteration: fixAgent 호출 → regenerateAllXcodeProjects → buildValidateIOS 재검증. training signal 매 iteration + 최종 signal. Android 패턴과 대칭화. → iOS 도 재빌드·재실행 경로 성립.
G63 crash context 프롬프트 주입 — index.ts fix task 에 [R24]|crash diagnostics 감지 시 2000자 전문 유지 + 원인 가이드 ("Info.plist 누락, CFBundleVersion 결함, Swift nil unwrap, entitlements 불일치") 포함. 기존 단순 "컴파일 에러 수정하세요" 프롬프트 폐기 (crash vs compile 구분). → ios_dev 가 스택/시그널 근거로 수정 가능.
G72 Simulator.app GUI 호출 — project-validator.ts:simulatorRunIOS simctl boot 직후 open -a Simulator --args -CurrentDeviceUDID <udid> 추가. GUI 실패는 계속 진행 (headless 가능성 대비). → Android emulator 와 시각적 대칭, 회장 실측 시 iOS 시뮬레이터 창 가시화.
G73 최종 빌드 게이트 — index.ts iOS/Android 빌드 섹션 진입 로그를 [G73:final] 최종 빌드 게이트 — 워커 코드 포함 전체 빌드+시뮬레이터+QA 검증 으로 마킹. 실체는 G61 retry-loop + G75 QA validation 로 이미 커버. → 워커 비즈니스 코드 반영 확정 검증.
G75 QA 실제 검증 격상 — project-validator.ts runQAValidationIOS/runQAValidationAndroid 신규. iOS: xcodebuild test + Test Case 'X' failed regex 파싱, pbxproj Tests 번들 존재 시에만 실행. Android: ./gradlew test + (\d+) tests completed, (\d+) failed 파싱, androidTest/test 디렉토리 존재 시에만. index.ts 빌드 PASS 후 자동 호출 → 실패 시 QA agent 재호출로 수정 루프. → "빌드 성공 = MVP 완료" 거짓 신호 소멸.
실측 검증 4대 항목 정의 — docs/realtest/realtest-standard.md Step 8.5 (신규 섹션) 표 추가. ① C레벨 대회의 ② 실시간 회의(60초 interval) ③ 하향 task 분할(DELEGATE→Parallel) ④ 상향 검증(Observer→Council→회장 alert). 각 항목 PASS 조건 + 로그 grep 키워드 + 해당 코드 위치 명시. 실측 보고서 말미 표로 기재 필수. → 자율 3축 동작 여부를 객관 판정 가능.

HOW TO VERIFY (실측073 대기):

grep "budget 상태" /tmp/bigboss_os_testNN.log → CTO 프롬프트에 budgetBlock 주입 확인 (G77)
grep "\[G73:final\]" /tmp/bigboss_os_testNN.log → 최종 게이트 호출 2회 이상 (iOS+Android)
grep "\[G75:QA" /tmp/bigboss_os_testNN.log → QA 실행 로그 (hadTests=true 시 pass/fail 숫자)
grep "iOS 빌드 에러.*retry " /tmp/bigboss_os_testNN.log → G61 while-loop retry N/3 진행 확인
grep "CFBundleVersion" /tmp/archi/실측테스트_NN/ios/.../project.pbxproj → G60 주입 확인
grep "Simulator.app GUI 창" /tmp/bigboss_os_testNN.log → G72 창 열기 시도
실측 보고서 "자율 3축 검증" 표 4항목 PASS 확인

IMPACT: 26 G-시리즈 중 9건 추가 해결 (G55/G60/G61/G63/G72/G73/G75/G77 + 실측4축). ① 통합 PR 과 함께 13건. 남은 CRITICAL 0. 남은 이슈는 MEDIUM/LOW (G48/49/50/51/53/56/57/62/64~71).

[2026-04-15] ① 자율 3축 통합 PR — G76+G82+G79+G81+ViewHolder

WHY: 자율은 "권한(G76) + 시그널(G82) + 학습(G79)" 3축이 동시에 성립할 때만 구조가 닫힌다. 분리 릴리스하면 한 사이클 관측 불가 — CTO 가 hire 못하면 Council 배치가 무의미, Council 이 침묵하면 학습 포인트 미검출, 학습이 없으면 G76+G82 가 같은 실수를 반복. 한 PR 통합 원칙(MEMORY: feedback_autonomy_three_axis) 준수.

WHAT:

ViewHolder 풀 리네임 — diamond-pool.ts → viewholder-pool.ts. getViewHolderPool() / VIEWHOLDER_POOL_SIZE. 기존 DiamondWorker/getDiamondPool alias 호환. RecyclerView 패턴 반영 — 워커 풀 재사용 의도 명시화.
G81 path-scoped Write/Edit — .claude/hooks/pre-code-check.sh 재작성. C레벨 agent (BIGBOSS_AGENT_ROLE=cto|coo|cfo|cmo|cpo|ciso|director) 는 docs/**, *.md, .ledger/ 만 허용. 나머지 deny + reason. 사람 유저 경로는 불변 (ask 유지). R2 "풀차단" 이분법 폐기.
G76 CTO hire 권한 — clevel-director.ts CTO 프롬프트에 [CLEVEL_PROPOSAL]{"role":"<id>","count":<n>,"reason":"..."} 블록 명세 추가. collectHireProposals() 파서 export. index.ts Phase 1 직후 proposeCLevelHiring() 호출 → CEO alert → 회장 승인 후 clevels INSERT. phase-detector 는 bootstrap fallback 으로 강등, CTO 판단 우선.
G82 Council 상시 + Observer 필터완화 — clevel-council.ts startCouncilReflectionLoop() — setInterval(60sec) + lastSeenCreatedAt 커서. messages 테이블 최근 1분 요약(SYSTEM_IDS 제외, agent 별 집계)을 trigger_type='roadmap_update' 로 ceo 명의 post. clevel-observer.ts — task_blocked 즉시 Council post (unchanged) + task_completed/progress 등 5건 또는 30초 window 로 배치 요약 post (enqueueBatch/flushBatch). setInterval 은 unref() 로 exit 차단 안 함.
G79 USF (Universal Skill Format) — docs/spec/usf.md 스키마 문서화. server/src/orchestrator/usf.ts — USFEntry 인터페이스 + frontmatter parser (gray-matter 회피, 의존성 제로) + captureSkill/promoteSkill/syncAllAdapters/getSkillsForRole. confidence 티어 proposed → verified → deprecated. ClaudeAdapter 는 ~/.claude/skills/bigbossos/{slug}.md 에 실설치 (proposed 는 ⚠️ proposed 마킹). Ollama/Codex/Gemma stub (v0.2 예정). index.ts 시작 시 syncUSFAdapters() 자동 호출. 시드 2종 — ios-bundle-validation.md (verified, 실측072 R24-B 기반), android-emulator-visibility.md (proposed, 실측072 Android 관찰 기반).

HOW TO VERIFY (실측073 대기):

C레벨 대회의 (부팅 시 Council startup log)
실시간 회의 (빌드 중 setInterval 반성회의 post 확인)
하향 task 분할 (CTO [CLEVEL_PROPOSAL] → CEO hire → 워커 분배)
상향 검증 (Observer task_blocked 즉시 + 배치 요약이 Council 에 올라옴)

IMPACT: 26 G-시리즈 중 4건 해결 (G76/G79/G81/G82) + ViewHolder 리네임. 남은 CRITICAL: G77/G73/G75/G61.

[2026-04-15] 실측072 결과 — G46/R24-B 검증 ✅ / G56·G61 재발견

결과: 🟡 부분 성공 · 2,543원 / 875초 / 22명 에이전트 · CEO 보고 큐 대기에서 종료 문서: docs/realtest/실측072.md

검증 성공:

G46 ✅ — CTO 0명, 리더급 0명, 워커 6명 + 도메인 워커 6명 전원(ios_dev_1/android_dev_1/biz_dev_1/designer_1/db_dev_1/api_dev_1) 정상 배치. project_id 필터 제거 후에도 role 기준 SELECT로 정상 동작.
R24-B ✅ — [R24:Simulator] 🔴 번들 정적 검증 실패 — 2건 (launch 차단) 재발동. CFBundleVersion:0 검출 → simulator 실행 전 차단 → ios_dev_1 재시도 + ScaffoldAgent pbxproj 재생성.
Android R24 ✅ — 앱 5초 생존 확인, 크래시 없음.

재발 이슈:

G56 재발 — [SpecIssuer] ❌ CTO Phase A1 실패: LLM timeout (180초). G58 Phase B 완화와 별개로 Phase A1 spec 타임아웃. 180→600초 파라미터화 필요.
G61 재확인 — ios_dev 수정 지시 이후 iOS xcodebuild + R24:Simulator 재실행 로그 없음. R17 chain의 iOS BuildValidator 재실행 경로 미구현 확정.
G60 연관 — ScaffoldAgent pbxproj 재생성이 여전히 CFBundleVersion:0으로 생성. Capomastro/scaffolding-agent 템플릿에서 CFBundleVersion 주입 누락이 근본 원인.

[2026-04-15] G46 근본 해결 — agents 워커 stateless 화 (project_id 박제 본질 제거)

WHY: 실측066~070 에서 워커 6명(android/api/biz/db/ios/designer) project_id='archi' 박제로 currentProjectId 기준 eq('project_id', currentProjectId) select 가 0건 반환 → CTO/COO 가 domain 워커 없음 → 스킵 → fallback director debate. 이전 패치(2026-04-15: 부팅 시 update(project_id=current).neq(project_id, current))는 증상 완화 — 멀티 프로젝트 동시 실행 시 또 박제됨. 다이아몬드 토론 수렴안: B (스키마 nullable 유지 + 워커 select 에서 project_id 필터 제거).

WHAT:

server/src/index.ts:436 부팅 시 박제 update 코드 완전 삭제 (증상 완화 코드 제거)
server/src/index.ts:454 printAgentRoster select 에서 .eq('project_id', currentProjectId) → .neq('id', 'director') 로 교체 (역할 기준)
server/src/index.ts:776 allHiredAgents select 에서 .eq('project_id', currentProjectId) 제거
server/src/orchestrator/llm.ts:751,823 routeDirective/callClaude 의 if (projectId) query = query.eq('project_id', projectId) 두 줄 제거 + void projectId 로 시그니처 호환 유지
server/src/test-pipeline.ts [5] G46 회귀 차단 2건 추가:

from('agents')[\\s\\S]{0,300}\\.eq('project_id' 패턴 grep — 0건 확인
from('agents').update({ project_id: 흔적 부재 확인

스키마:

agents.project_id 컬럼은 036_agents_project_dir.sql 에서 이미 DEFAULT NULL (nullable). migration 불요.
컬럼 자체 제거는 향후 cleanup 단계로 격하 (다른 테이블 FK 영향 점검 후)

검증:

tsc clean
test-pipeline 58/58 (R24 56 + G46 2)
프로덕션 rsync 완료

재발 차단:

"박제" 패턴이 코드에 다시 나타나면 test-pipeline 가 즉시 fail.
멀티 프로젝트 동시 실행 시에도 워커는 role 기준으로만 매칭되어 박제 자체가 불가능.

[2026-04-15] 실측071 ✅ — R24 실전 검증 + G60/G61 신규 발견

결과: ✅ 성공, 2,622원, iOS/Android/API 모두 BUILD SUCCEEDED, CLI 응답 완료 14:30:56.

R24 실전 발동 (핵심):

14:22:35 BuildValidator:iOS xcodebuild 성공
14:23:01 [R24:Simulator] 🔴 번들 정적 검증 실패 — 2건 (launch 차단) — Capomastro 생성 Info.plist 의 CFBundleVersion:0 감지, simulator launch 자체 차단
14:23:01~14:28:37 ios_dev_1 자동 재시도 루프(6회)로 Info.plist 수정 → 최종 BUILD SUCCEEDED
simulator crash 발생 0건 — R24-B 정적 게이트가 launch 전에 차단해 crash 클래스 자체 소멸

G55/G58 후속 관찰:

CTO/COO Phase A1+A2 모두 성공(타임아웃 0건) — G55 재검증
COO Phase B [raci] 성공 — G58 5분 상한 충분
CTO Phase B [raci] 5분 timeout 1건 — CTO 컨텍스트가 더 큼. 비동기 백그라운드라 critical 아니나 G58 추가 조정 여지(프롬프트 분할 or 8분 상한)

신규 이슈:

G60 (HIGH): Capomastro/scaffolding 단계 Info.plist 에 CFBundleVersion 누락. R24-B 가 잡지만 본질은 생성 단계 결함.
G61 (MEDIUM): BuildValidator:iOS 가 ios_dev 수정 후 재실행 미확인. R17 chain 의 빌드 재검증 경로 점검 필요.

다음 단계: 폭포수 ② = G46 (agents.project_id 박제 근본 해결).

[2026-04-15] R24 근본 해결 — iOS 시뮬레이터 crash 진단 채널 + 번들 정적 게이트 (A+B)

WHY: 실측070 에서 시뮬레이터 launch 후 즉시 crash, ios_dev 가 재시도 루프에 빠짐. 원인은 simulatorRunIOS() 가 launch 결과 stderr 200자만 BuildError.message 에 담아 LLM 에게 전달 — stack trace/exception type/termination reason 부재로 LLM은 매번 추측만 함. 회장 12기준 중 Generate-Verify(검증 신호 부재) + 폭포수 우선순위 CRITICAL 1건.

WHAT (다이아몬드 토론 수렴안: A 우선 + B 보조):

A) crash 진단 자동 수집 (server/src/orchestrator/project-validator.ts):

collectIOSCrashContext(udid, bundleId, projName) 헬퍼 신설.

~/Library/Logs/DiagnosticReports/ 디렉토리에서 mtime 최근 5분, 확장자 .ips/.crash, process/bundle 문자열 매칭 8건 중 첫 매칭 파일 head 16KB 읽어 extractCrashSummary() 로 Exception Type/Subtype/Codes/Termination Reason/Termination Description + Thread N Crashed: 상위 15 frames 추출.
xcrun simctl spawn <udid> log show --predicate 'processImagePath CONTAINS "<projShort>"' --last 1m --style compact tail 30 라인.
두 소스 합쳐 4KB 상한.

simulatorRunIOS() 두 실패 경로(launch 즉사 / 5초 내 프로세스 소멸) 모두에서 호출 → BuildError.message 에 --- crash diagnostics --- 섹션으로 첨부. 5초 crash 의 경우 simctl terminate/shutdown 이전에 수집(종료 후 log 회수 불가 회피).

B) 번들 정적 게이트 (server/src/orchestrator/project-validator.ts):

validateIOSAppBundle(appPath) 헬퍼 신설(BundleIssue[] 반환).

Info.plist 존재 + plutil -lint 통과
plutil -convert json 후 필수 키 검증: CFBundleIdentifier, CFBundleVersion, CFBundleShortVersionString, CFBundleExecutable (누락 또는 공백 빈 값 모두 fail)
존재 시 PrivacyInfo.xcprivacy plutil -lint
존재 시 archived-expanded-entitlements.xcent plutil -lint

simulatorRunIOS() 의 Bundle ID 추출 직전에 호출. 이슈 ≥1건이면 launch 자체를 차단하고 BundleIssue 들을 BuildError 로 매핑 → ios_dev 가 정확한 키/이유 받음.

C) 회귀 차단 (server/src/test-pipeline.ts [4] validateIOSAppBundle 7건):

정상 번들 0건
Info.plist 없음 1건 + 메시지 매칭
CFBundleIdentifier 누락 / 빈 값 각각 감지
깨진 plist plutil -lint 실패 감지
깨진 PrivacyInfo 감지
정상 번들 + 정상 PrivacyInfo 0건

검증:

tsc clean
test-pipeline 56/56 (기존 48 + R24-B 7 + helper 1)
프로덕션 rsync 완료(/Users/cavss/Desktop/bigbossos/server/src/)

재발 차단:

"왜 죽었는지 모르는" launch 즉사 케이스 자체 소멸 — 번들 결함은 launch 전, 런타임 crash 는 stack trace 포함.
다음 실측071 에서 시뮬레이터 crash 발생 시 LLM 입력에 stack trace 가 포함되는지 1건 검증으로 close 가능.

남은 작업:

폭포수 단계 2: G56 (실측071 R17 chain 자연 소멸 확인)
폭포수 단계 3: G46 (agents.project_id 스키마 nullable 전환)

[2026-04-15] G58 근본 해결 — `callStatelessForDocs` 호출자별 타임아웃 파라미터화

WHY: 실측070 Phase B 에서 [raci] 와 [gantt] 양쪽 모두 3분 타임아웃 재현(빈도 확정). G55 로 Phase A 타임아웃을 5→3분으로 낮췄는데 동일 함수가 Phase B 에도 재사용됐고, Phase B 는 wbsCtx(최대 3000자) 를 프롬프트에 주입하므로 Phase A 보다 훨씬 큰 컨텍스트. 3분 상한이 타이트해 간헐 타임아웃 발생 → raci/gantt 문서 품질 저하(비동기 백그라운드라 critical 아님).

WHAT:

server/src/orchestrator/spec-issuer.ts:

callStatelessForDocs(prompt, cwd, timeoutMs: number = 3 60 1000) — 세 번째 파라미터로 상한 주입
내부 setTimeout(…, timeoutMs) + 에러 메시지에 ${timeoutSec}초 동적 출력
Phase A(spec/tasks) 호출부는 기본값 3분 유지 — 소형 프롬프트
Phase B(docQueue 내 [raci]/[gantt] 등) 호출부는 5 60 1000 명시 — wbs 컨텍스트 주입 반영

tsc + test-pipeline 48/48 통과, 프로덕션 rsync 완료

재발 차단:

같은 함수가 이질적 프롬프트 크기로 재사용될 때 상한을 호출자별로 명시해 "가장 작은 프롬프트 기준 상한이 가장 큰 프롬프트를 자를 수 있는" 구조 제거.

남은 작업:

실측071 에서 Phase B raci/gantt 타임아웃 0건 재확인
R24 iOS 시뮬레이터 crash 원인 분리 조사 (G58 과 무관)

[2026-04-15] G57 근본 해결 — BuildValidator:iOS 에러 파싱 보강 + BUILD FAILED 항상 보고

WHY: 실측069에서 xcodebuild 이 BUILD FAILED 출력했는데 BuildValidator 는 "🔴 xcodebuild 에러 0건" 로그 남기고 빈 배열 반환. 다운스트림은 "에러 없음=성공" 으로 해석 → test-record 자동 판정이 "성공" 으로 분류. 실제는 G59 원인으로 ContentView.swift 경로 해결 실패(project-level error). 회장 12기준 중 Generate-Verify 위반.

WHAT:

server/src/orchestrator/project-validator.ts:343-383 catch 블록 재작성:

buildFailed = output.includes(' BUILD FAILED ') — 빌드 실패 시그널 자체를 검사
기존 Swift 에러 패턴 유지 + project-level ^error:\\s+(.+)$ 패턴 추가 (Build input files / linker / signing 등)
BUILD FAILED 인데 두 패턴 모두 0건이면 합성 에러 1건 주입 — 다운스트림이 "0건=성공" 으로 오인 불가
로그 🔴 BUILD FAILED — 에러 N건 또는 🔴 xcodebuild 예외 — 에러 N건 — 상태/건수 분리 명시

tsc + test-pipeline 48/48 통과

재발 차단:

BUILD FAILED 는 이제 반드시 ≥1 에러로 표면화 — 배열 길이만 보는 소비자 코드도 자동으로 실패 처리
로그 문구에서 "0건" 이 단독으로 나오는 실패 경로 제거

영구 규칙 후보 (메모리):

외부 도구(xcodebuild/gradle 등) 출력을 파싱할 때 실패 시그널 문자열(BUILD FAILED, FAILURE: 등)을 우선 검사하고, 에러 개수 0이어도 해당 시그널이 있으면 합성 에러로 승격시켜야 다운스트림 오인 차단.

남은 작업:

실측070: G54+G55+G57+G59 종합 검증. BuildValidator 보고와 실제 빌드 결과 일치 여부 자동 판정
G58 Phase B raci 타임아웃 빈도 관측

[2026-04-15] G59 근본 해결 — `toRel()` 을 Node `relative()` 로 교체 + test-pipeline 실전 검증 추가

WHY: 실측069에서 G54 수정 적용 후에도 xcodebuild Build input files cannot be found: .../ios/StreamApp/StreamApp/StreamApp/ContentView.swift 발생. 원인은 buildPbxproj.toRel() 의 abs.indexOf('/${groupRoot.lastSeg}/') 가 ios/<name>/<name>/ 구조에서 첫 /StreamApp/ 를 잡아 잘못된 StreamApp/ContentView.swift 반환 — 그룹 path(StreamApp)와 합쳐져 StreamApp/StreamApp/ContentView.swift 이중화. plutil -lint 는 syntax만 검증하므로 test-pipeline 게이트가 놓쳤음.

WHAT:

scaffolding-agent.ts:345-377:
buildPbxproj 시그니처에 srcDir, testsDir, uitestsDir 절대경로 3개 추가
toRel() 삭제 → relative(groupDir, abs) 로 교체. Node 표준 경로 계산이라 edge case 없음
호출부 regenerateXcodeProject 에서 3개 디렉토리 전달
test-pipeline.ts [3] 섹션에 신규 게이트 5건:
xcodebuild -list 통과 (파일 참조 해결 단계 포함)
pbxproj 모든 PBXFileReference path 가 실제 파일 매칭(main/tests/uitests 그룹 기준) — 이중 경로 직접 차단
48/48 통과
실측069 pbxproj 재생성 후 xcodebuild ... build = BUILD SUCCEEDED 실전 검증

재발 차단:

indexOf 기반 ad-hoc 경로 추출 전면 제거. Node relative() 만 사용
test-pipeline 에 "syntax OK" 만으로 통과하는 상태 제거 — 실제 파일 해결 확인

영구 교훈 (feedback 메모리 후보):

pbxproj 같은 구조화 포맷의 단위 테스트에서 lint/syntax 검증은 1차 게이트일 뿐. 실제 소비자(여기선 xcodebuild)가 의미론적으로 받아들이는지 확인하지 않으면 G59 급 버그 놓침.

남은 작업:

G58(Phase B raci 3분 타임아웃) 검토 — 빈도 관측 후 조치
G57(BuildValidator 에러 0건 오보) — xcodebuild BUILD FAILED 감지 누락. 별도 근본 해결 필요

[2026-04-15] G55 근본 해결 — SpecIssuer Phase A를 spec-only + tasks-only 2 call로 분리

WHY: 실측068에서 SpecIssuer CTO가 5분 타임아웃으로 Phase 1 결과물 누락 → R17 연쇄 실패(G56) 유발. 과거 G35("타임아웃을 10분으로 연장")는 증상치료였음 — 회장 영구 규칙 "증상완화 금지 + 초기/중기/장기 분할 금지" 위반 이력. 진짜 원인: Phase A가 spec+tasks 2문서를 1 call에 묶어 출력 볼륨 초과 → CTO(9 워커=가장 큰 tasks doc)가 첫 timeout 희생양.

WHAT:

server/src/orchestrator/spec-issuer.ts:
buildSpecIssuerPrompt() 삭제 → buildSpecOnlyPrompt() + buildTasksOnlyPrompt(specContext) 신설
issueCLevelDocs() Phase A 재작성: A1(spec 1 call) → A2(tasks 1 call, spec 결과를 컨텍스트로 주입) 순차. 각각 실패 시 독립 early-return으로 부분 성공 상태 보존
callStatelessForDocs 타임아웃 5분 → 3분 축소 (문서 1개=1 call 원칙에 맞춘 현실적 상한)
G38 "문서1개=1 call" 원칙을 Phase B에만 적용하던 것을 Phase A에도 확장 → 전 파이프라인 동일 원칙
tasks가 spec 결과를 참조 → 워커·산출물 일관성 보장(1-parse-share-all 철학)
npx tsc --noEmit 통과, test-pipeline.ts 42/42 통과

재발 차단:

"문서1개=1 call" 규칙이 전 Phase에 적용 — 2문서 이상 묶기 자체가 구조적으로 불가
타임아웃 5분→3분으로 축소해도 여유 — 향후 출력 팽창 조기 감지

남은 작업:

서버 재기동 후 실측069로 end-to-end 검증 (CTO Phase 1 결과물 실제 생성 여부)
G56(R17 연쇄 실패 재평가) / G57(계측 모순) 후속 근본 해결

[2026-04-15] G54 근본 해결 (2차) — `syncXcodeProjects` 삭제 + `regenerateXcodeProject` 전면 교체

WHY: 1차 수정(regex opener 분리)은 증상완화. 회장 지시 "증상완화가 아닌 근본적이고 본질적인 원인 자체를 해결한다 + 초기/중기/장기로 분할하지 말고 지금 바로 해결한다". pbxproj(OpenStep plist, context-free 문법)를 정규식으로 편집하는 구조 자체가 G27/G28/G54 반복 근본. 회장의 영구 에러수정 규칙 확립.

WHAT:

syncXcodeProjects() 삭제 — project-validator.ts 1058-1194줄 제거 + createHash import 제거
신규 scaffolding-agent.ts:
buildPbxproj(opts, main[], tests[], uitests[]) — 파일 목록 → pbxproj 전체 문자열. UUID는 sha256("scope:name:group:relPath").slice(0,24).toUpperCase()로 결정론적 생성
regenerateXcodeProject(projectDir, {name, pkg, minVersion}) — 디렉토리 스캔 + pbxproj 재작성
regenerateAllXcodeProjects(projectDir, iosMinVersion?) — syncXcodeProjects 드롭인 대체 (pkg 는 기존 pbxproj PRODUCT_BUNDLE_IDENTIFIER에서 추출, 깨지면 com.example.<name> 폴백)
writeIOSScaffold() 도 regenerate 경로로 위임 — swift/asset/xcworkspace 기록 후 regenerateXcodeProject 호출
index.ts:47 import 교체, 1445/1535 호출부 교체
test-pipeline.ts [3] 섹션 10건 추가 — fixture 프로젝트 생성 → regenerate → ① 이중 opener 금지 ② 서브디렉토리 swift 포함 ③ iOS deployment target/bundle id 주입 ④ plutil -lint 통과 ⑤ 결정론(두 번 호출 결과 바이트 동일). 42/42 통과
실측068 /Users/cavss/Desktop/archi/실측테스트_068/ios/StreamApp 재생성 → plutil -lint OK + xcodebuild -list 3 targets 정상 출력 확인

재발 차단:

regex pbxproj 편집 코드 전면 제거. 앞으로 pbxproj 변경은 전체 재생성만 가능(buildPbxproj만 수정 대상)
test-pipeline.ts 게이트로 0원 회귀 검증

영구 규칙 기록:

메모리 feedback_root_cause_no_phases.md — "증상완화 금지 + 위상 분할 금지"

남은 작업:

서버 재기동 후 실측069로 end-to-end 검증
G55(SpecIssuer 5분 타임아웃 재발) / G56(R17 연쇄 실패) / G57(보고 상충) 순차 근본 해결

[2026-04-15] G54 1차 시도 (superseded) — regex opener 분리 땜빵

WHY: 실측068에서 iOS 빌드 전면 실패. xcodebuild project 'StreamApp' is damaged. Ruby xcodeproj gem(nanaimo 파서) 진단으로 children = (children = ( opener 이중 삽입 확인.

WHAT:

project-validator.ts:1158-1181 regex를 /UUID([\s\S]?)(children = $)([^)])$/로 opener 분리. files 섹션도 동일.
회장 판정: 증상완화. 근본은 "regex로 pbxproj 편집" 패턴 자체 → 2차 수정으로 syncXcodeProjects 전체 삭제로 이행.

[2026-04-15] G47 근본 해결 — supabase.ts 폴링 주 / Realtime 부 역전

WHY: 실측067에서 Realtime SUBSCRIBED 후 조용히 이벤트 미전달 + 폴링 fallback 미개시로 90분 침묵. 원인: realtimeOk=true 할당 후 상태 전환 이벤트가 안 오면 startPolling 호출 경로가 없음. 상태 기반 분기 설계가 Supabase 인프라 신뢰성에 의존하는 잘못된 가정.

WHAT:

server/src/orchestrator/supabase.ts:300-408 subscribeToMessages 재설계
폴링 항시 구동(3초), Realtime 이벤트는 같은 callback으로 병행 수신
lastSeenId > msg.id 체크로 중복 제거 (Realtime/폴링 어느 쪽이 먼저 잡아도 OK)
realtimeOk 변수 + 상태 전환 기반 startPolling/stopPolling 제거
실측068 검증: 폴링 38건 + Realtime 165건 이중 수신 실증, 067 silent death 재현 안 됨

[2026-04-15] G45/G46 발견 + 수정 — 실측066 첫 실행

WHY: migration 062 적용 후 첫 실측. 파이프라인 회귀 검증.

G45 발견: 서버 부팅 시 A4 재개 로직이 stale work_state(msgId=24792, channel_id='pm_ceo')를 재삽입 → FK 위반.

G45 수정:

node+pg로 stale work_state 레코드 status='completed' 마킹 (msgId=24792)
index.ts A4 코드에 LEGACY_CHANNELS·LEGACY_AGENTS 가드 상수 추가, 매핑·필터 적용
재기동 검증: A4 FK 에러 0건

G46 발견 (실측066 실패):

워커 6명이 DB에 project_id='archi'로 박제
서버 부팅 시 update project_id=current WHERE project_id IS NULL 쿼리가 'archi' 값을 놓침
CLevelDirector가 current project_id로 워커 조회 → 0건 → "도메인 워커 없음 스킵"
Phase 1 0.5초 만에 완료 → 구조적 보정(Director Debate) 폴백 → 192원 소진, 코드 생성 0건

G46 수정: server/src/index.ts:436 .is('project_id', null) → .neq('project_id', currentProjectId) — 서버 시작 시 모든 에이전트를 현재 프로젝트로 재할당. dev 단일 프로젝트 모드에서만 안전, 향후 멀티 프로젝트 도입 시 재설계 필요.

사이드 조치:

CLI Company → BigBoss OS 전면 치환(배너 ASCII, docker-compose, bin/test-record, bin/guardian, bin/metrics-cron, summary.md, migrations 001/002, setup.sql, .env.example)
서버 부팅 배너 갱신 확인 (실측066 log 25초 구간)

실측066 결과: ❌ 실패 (G46 블로커). 비용 192원. 상세: docs/realtest/실측066.md

남은 작업: G46 수정 검증 위한 실측067 실행 (회장 승인 후).

[2026-04-15] G44 해결 — migration 062 DB 적용 (pm_ceo → chairman, PM/Director 패기)

WHY: 회장 지시 2026-04-15로 pm_ceo 채널 → chairman 단일화, PM/Director 중간관리자 레이어 패기. 서버·대시보드·iOS·Android·setup.sql·realtest-standard.md 전부 chairman 기준으로 사전 수정 완료. DB 미적용 시 RLS agent_id='chairman' CHECK가 막혀 회장 메시지 INSERT 전부 실패 위험 — 실측 재개 블로커.

조치:

supabase login (브라우저 인증, 2026-04-15 00:55)
supabase link --project-ref uvyivtjxmpkkduffbtnb 완료
supabase db push 실행 → 원격 migration history 비어있음 확인(ERROR: "agents" already exists)
supabase migration repair --status applied 001..061 일괄 표시
중복 버전 파일(002_security_docker.sql, 003_kanban_docker.sql) 재시도 실패 → node+pg로 062 SQL 직접 실행(TX OK)
migration repair --status applied 062 최종 표시

검증 (프로덕션 DB):

channels 테이블: chairman 1행 존재, pm_ceo · pm_report 0행
agents 테이블: pm · director 0행
messages_insert_anon / messages_insert_authenticated RLS 정책 재생성 확인

남은 작업:

실측066 Step 2부터 재개 (개발 단계 — 앱 재배포 대신 로컬 빌드로 검증)

[2026-04-14] G43 수정 — Director 2차 DELEGATE 미처리 (CTO→Director→Dev 2단계 위임)

WHY (발견 경위): 실측063에서 투입 에이전트 1명 (director)만 실행되고 iOS/Android/API 빌드 전부 미실행. Director 로그 확인 결과, Director가 정상적으로 [DELEGATE] api_dev / ios_dev / android_dev [/DELEGATE] 를 출력했으나, 서버가 이 2차 DELEGATE를 처리하지 않음.

근본 원인: Phase 1 C레벨(CTO)이 director를 delegate로 지정 → parseDelegates regex fallback으로 director 파싱 → director가 worker로 callAgentsParallel에 투입됨 → director의 출력(ios/android/api DELEGATE)을 서버가 읽지 않고 summary만 추출함.

수정 (server/src/index.ts):

Main pipeline G43 block (callAgentsParallel 직후):

director/cto 역할 결과에서 [DELEGATE] 블록 파싱
Phase 2 스캐폴딩 → callAgentsParallel 재실행
delegates, delegateRoles 업데이트 → 이후 빌드 검증 정상화

alert_response 경로: DB 미등록 에이전트에 역할 기반 기본 시스템 프롬프트 fallback
const delegateRoles → let delegateRoles (재할당 가능화)

[2026-04-14] Diamond Debate v5 — 수렴 집착 제거, 탐색 완료 모델로 재설계

WHY (설계 철학 변경):

Diamond Debate의 원래 목적은 "더 나은 해결안을 도출하는 것"이었는데, weaknesses=0 수렴 조건에 집착하면서 시스템이 왜곡됐다.

실제로 T2/T3의 잔존 약점 ("Redis fail-open DDoS 창", "BLPOP 재구독 메시지 손실")은 실패가 아니라 이 솔루션이 가진 알려진 트레이드오프 목록 — 진짜 가치 있는 출력이다.

재정의:

기존: 수렴 = 약점이 없어질 때까지 반복
신규: 탐색 완료 = 더 이상 새로운 발견이 없을 때 자연 종료

구조 변경:

항목	기존	변경
종료 조건	weaknesses=0 또는 MaxLevel 강제	약점 집합 정체 감지 (자연 종료)
MaxLevel	4 (토론 차단)	20 (비상 탈출용만)
`converged`	수렴 여부 (실패 신호)	제거
`unresolvedWeaknesses`	미해결 약점 (실패 목록)	`knownTradeoffs` (발견된 트레이드오프)
`settled`	없음	추가 — 자연 종료 여부
잔존 약점 의미	실패	이 솔루션의 알려진 한계 (가치 있는 출력)

정체 감지 로직 (자율주행 수렴):

코드가 hybrid 약점 집합을 비교. LLM에게 "수렴했냐" 묻지 않음
stallCount >= 2 (2회 연속 동일) → 탐색 완료 자연 종료
weaknesses=0 → 완전 해결 (최상의 케이스)

MaxLevel=10 (비상 탈출 상한):

정체 감지 정상 작동 시: 3-4회 팬아웃에서 자연 종료 (600-800초)
MaxLevel=10: 최대 5회 팬아웃, 최대 ~1000초 (17분) 비상 탈출 보장

v5 sonnet 3회 테스트 결과 (모델: sonnet / Pool:3 / MaxLevel:10):

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	⚠️비상탈출	⚠️비상탈출	✅탐색완료
레벨	10	10	6
노드	26	26	16
폐기	0	0	0
소요	1434초	1212초	733초
트레이드오프	2개	3개	0개

총 비용: $5.37 (₩7,786)

v5 평가:

T3 최초 완전 탐색 완료 ✅ ("실시간 채팅" 문제는 4개 도메인이 명확한 합의점 도달)
T1/T2 비상탈출 — stall detection 미발동 (G8 문제)
약점 카운트 추이: T1 L2(3)→L4(3)→L6(2)→L8(2)→L10(2) / T2 L2(5)→L4(3)→L6(3)→L8(3)→L10(3)
G7-D 미적용 (테스트 시작 후 패치) → Director 출력 폭발 여전히 존재

신규 발견 — G8: Stall Detection 결함 (v5에서 발견)

WHY (G8 패치 필요 이유):

v5의 stall detection이 T1/T2에서 한 번도 발동하지 않은 근본 원인:

normalizeW = s.slice(0, 30) 텍스트 비교에 의존
LLM은 같은 의미의 약점을 매 레벨마다 다르게 표현 (자연어 재표현)
결과: 약점 수가 2→2→2로 고정돼도 텍스트가 달라서 stallCount 리셋

카운트 기반 감지가 정답인 이유:

약점 수가 감소하지 않는다 = 도메인 에이전트가 더 이상 새로운 해결 불가
표현 방식 변화는 노이즈 (같은 아키텍처 문제를 다르게 서술)
T1/T2 회고: count-based였다면 T1 L10→탐색완료, T2 L8→탐색완료 (2 fan-out 절약)

G8 구현 완료 — count-based stall (diamond-debate.ts):

prevWeaknessSet, normalizeW, currWeaknessSet, isStalled 전체 제거
prevWeaknessCount: number = -1 하나로 대체
isStalled = currCount > 0 && currCount === prevWeaknessCount
stallCount > 0 시 [DiamondDebate] 정체 감지 stallCount=N 로그 출력

G8 예상 효과 (v5 데이터 기준 회고):

T1: L8(약점:2)=L6(약점:2) → stallCount=1, L10(약점:2)=L8 → stallCount=2 → 탐색완료 (MaxLevel과 동일 레벨)
T2: L6(약점:3)=L4(약점:3) → stallCount=1, L8(약점:3)=L6 → stallCount=2 → L8에서 탐색완료 (2 fan-out 절약, ~400초)
T3: 영향 없음 (약점:0 자연 종료가 먼저)

[2026-04-14] Diamond Debate v6 — G7-D + G8 실측 결과

v6 테스트 결과 (sonnet / Pool:3 / MaxLevel:10):

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	✅탐색완료	⚠️비상탈출	⚠️비상탈출
레벨	6	10	10
노드	16	26	26
소요	570초	833초	912초
트레이드오프	2	3	4

총 비용: $4.03 (₩5,850) — v5($5.37) 대비 -25%

G7-D Director 출력 실측:

Level	v5 T1	v6 T1	감소율
L2	8,692자	2,802자	-68%
L4	13,470자	2,671자	-80%
L6	20,759자	2,476자	-88%
전체	최대 27,589자	최대 3,502자	-87%

→ G7-D 500-word 캡 완벽 작동. 모든 레벨에서 2,000~3,500자 안정.

G8 실측:

T1: L2(2)→L4(2, stall=1)→L6(2, stall=2) → 탐색완료 L6 ✅ (v5: L10 비상탈출)
T2: L8(3)→L10(3, stall=1) → MaxLevel 도달 → 비상탈출 (stall=1 미달)
T3: 약점 진동(3→3→2→4→4, stall=1) → MaxLevel 도달 → 비상탈출

신규 발견 — v6 T3 퇴보:

v5 T3: Level 6, 733초, 약점:0 ✅탐색완료
v6 T3: Level 10, 912초, 약점:4 ⚠️비상탈출
원인 분석: G7-D 500-word 캡으로 Director가 복잡한 문제(실시간 채팅) 완전 합성 불가 OR v5 T3가 허수 수렴(긴 출력으로 약점을 덮어버린 것)
약점 진동(3→3→2→4)은 Director가 안정적인 합성을 못하고 있음을 시사

신규 발견 — T2/T3 MaxLevel 문제:

T2 약점 진동: L2(2)→L4(3)→L6(4)→L8(3)→L10(3) — stallCount 최대 1
T3 약점 진동: L2(3)→L4(3)→L6(2)→L8(4)→L10(4) — stallCount 최대 1
STALL_THRESHOLD=2는 진동 패턴에서 한 번도 발동 안 됨
MaxLevel=10에서도 해결 안 된 문제들 → 진짜 어려운 아키텍처 트레이드오프

신규 발견 — v6 T3 "퇴보" 로그 분석 결과:

로그 직접 확인으로 원인 확정:

v5 T3 약점:0은 허수 수렴이었다

v6 T3 L10 트레이드오프: 물리 DMA/cold-boot, 커널 루트킷 Frida, Sybil 공격(소규모 룸), Hard Block appeal SLA
이것들은 앱 레이어 해결 불가한 하드웨어/OS 레벨 구조적 한계
v5 Director는 8k자 답변에서 이 문제들을 언급만 하고 WEAKNESSES에 기재하지 않음 → 가짜 수렴
G7-D가 Director를 더 정직하게 만든 것 — v6가 더 정확한 결과

G9 필요 — WEAKNESSES fix 내부 쉼표 파싱 버그

L8에서 실제 약점 3개 → 4개로 집계됨
원인: 공개 CT 로그 Eclipse Attack|다중 IP gossip 수신 강제로 부분 완화, 미완전 해소 에서 fix 내부 , 를 parseList가 항목 구분자로 처리
"미완전 해소" (fix의 접미사)가 독립 약점으로 파싱됨
G9 수정: fix 내부 쉼표(| 이후)는 구분자 제외, 또는 Director 프롬프트에 "fix 내부 쉼표 금지" 지시

G9 구현 완료 — diamond-filter.ts parseWeaknessList:

parseList → WEAKNESSES 전용 parseWeaknessList로 교체
, <word>| 패턴을 항목 경계로 인식 → fix 내부 쉼표는 구분자 제외
예: risk1|fix with, commas, risk2|fix2 → 2개 올바르게 파싱 (기존: 4개 오파싱)

[2026-04-14] Diamond Debate v7 — G9 실측 결과 (최종)

v7 테스트 결과 (sonnet / Pool:3 / MaxLevel:10):

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	✅탐색완료	✅탐색완료	⚠️비상탈출
레벨	6	8	10
노드	16	21	26
소요	529초	706초	976초
트레이드오프	2	3	3

총 비용: $3.79 (₩5,499)

버전별 전체 비교:

	v5	v6	v7
T1	⚠️ 1434초	✅ 570초	✅ 529초
T2	⚠️ 1212초	⚠️ 833초	✅ 706초
T3	✅ 733초*	⚠️ 912초	⚠️ 976초
비용	$5.37	$4.03	$3.79
탐색완료	1/3	1/3	2/3

*v5 T3는 허수 수렴 (긴 출력으로 약점 은폐)

G9 효과 확인:

T2: 비상탈출→탐색완료 전환 ✅ (L6→L8 stall=2 자연 종료)
T3 L2: 약점:3(v6)→약점:1(v7) — 파싱 노이즈 대폭 감소
파싱 정확도 향상으로 stallCount가 진짜 트레이드오프에서만 발동

T3 비상탈출 분석:

약점 추이: L2(1)→L4(2)→L6(2,stall=1)→L8(3,reset)→L10(3,stall=1)
L8에서 약점 증가(2→3): domain agents가 보안·E2E·확장성 새 이슈 계속 발굴
"실시간 채팅" 문제의 본질적 복잡성 — 10 레벨 안에 모든 도메인 트레이드오프 수렴 불가
트레이드오프 3개는 진짜 아키텍처 한계 (로그 직접 확인 예정)

미해결 과제:

T3 비상탈출: 복잡한 문제에서 약점 증가 패턴 반복 — MaxLevel 증가 or STALL_THRESHOLD 조정 고려
autoPrune 여전히 미발동 (노드 수 고정)

[2026-04-14] G10 — T3 MaxLevel=12, G11 — 모델 기입, G12 — Ollama/Gemma 4 31B 연동

G10: T3 MaxLevel=12

WHY:

v7 T3: L8에서 stallCount=1 → L10(MaxLevel)에서 비상탈출. stallCount=2 달성까지 레벨 1개 부족
T3 "실시간 채팅" 문제는 진짜 복잡한 아키텍처 트레이드오프 — MaxLevel=12면 자연 종료 예상
MaxLevel은 비상 탈출용 상한이므로 12로 늘려도 정상 수렴 시 영향 없음

변경: test-diamond-suite.ts DIAMOND_MAX_LEVEL=10 → 12

G11: 테스트 보고서 모델 기입

WHY:

기존 실측 데이터(v4~v7)가 haiku/sonnet 혼재 — 어떤 모델로 돌린 결과인지 기록 없음
향후 Gemma vs Sonnet vs Haiku 비교 분석 시 모델 정보 필수
TestReport에 domainModel/directorModel 필드 추가, 보고서 표에 기입

G12: Ollama/Gemma 4 31B Diamond 에이전트 연동 (Phase 1)

WHY:

Soldato(Claude API) 장기 대체 로드맵 Phase 1: Diamond Debate 도메인 에이전트부터 교체
Gemma 4 31B Dense Q4_K_M (20GB): 로컬 Ollama, 32GB+ Mac 필요, Sonnet 중간 품질 목표
데이터 플라이휠 시작점 — 실사용 데이터 수집으로 장기 파인튜닝 준비
모델명 prefix 규약: ollama:<model-tag> → Ollama HTTP API 라우팅 (예: ollama:gemma4:31b)

변경:

llm.ts: callOllamaAgent() 추가 — Ollama HTTP API (POST /api/chat) 호출
diamond-pool.ts: runOnWorker에서 모델명 ollama: prefix 감지 → Ollama 라우팅
환경변수: DIAMOND_OLLAMA_URL (기본 http://localhost:11434)

구현 완료:

server/src/orchestrator/llm.ts — callOllamaAgent() 추가 (G12)
server/src/orchestrator/diamond-pool.ts — import + isOllama 분기 (G12)
server/src/test-diamond-suite.ts — MaxLevel=12 (G10), TestReport 모델 필드 + writeReport 실행환경 섹션 (G11)

사용법 (Gemma 4 31B):

DIAMOND_MODEL=ollama:gemma4:31b \
DIAMOND_DIRECTOR_MODEL=ollama:gemma4:31b \
DIAMOND_OLLAMA_URL=http://localhost:11434 \
npx tsx src/test-diamond-suite.ts

Ollama가 로컬에서 실행 중이고 gemma4:31b 모델이 다운로드된 상태여야 함 (ollama pull gemma4:31b)

v8 예상 (G10 MaxLevel=12):

T3: L10(stall=1) → L12(stall=2) → 자연 종료 예상
T1/T2: 이미 자연 종료 — MaxLevel 변경 영향 없음

[2026-04-14] G13 — Training Data Capture (증류/파인튜닝/데이터 플라이휠)

WHY:

Diamond Debate v8부터 실측 데이터를 파인튜닝 포맷으로 동시 저장. MD 보고서(최종 답만)로는 증류 불가 — 중간 추론 과정 전체가 학습 데이터임.

목적별 필요 데이터:

목적	핵심 데이터	비고
증류 (Opus→Gemma)	system_prompt + user_message + raw_output	교사-학생 학습 쌍
SFT 파인튜닝	위 + quality 필터 (pruned 노드 제외)	고품질 출력만 학습
데이터 플라이휠	debate 수준 메타 (문제→결과 추적)	시간별 개선 측정

캡처 포인트 (우선순위순):

generateFixAttempt — domain agent 호출 (tech/security/ux/cost). Gemma 교체 1순위 대상.
runDiamondDebate 완료 시 — debate 전체 요약 (플라이휠용)

NodeRecord 스키마 (nodes.jsonl):

schema, captured_at, debate_id, node_id, node_type, domain, level, model
system_prompt, user_message, raw_output (증류용 teacher output)
strengths, weaknesses, observations, solution (파싱된 구조화 출력)
node_status (active/pruned/leaf/final), parent_weakness_count, own_weakness_count (품질 신호)

DebateRecord 스키마 (debates.jsonl):

debate_id, problem, initial_solution, model_domain, model_director
settled, total_levels, total_nodes, pruned_nodes
initial_weakness_count, final_weakness_count, final_answer, known_tradeoffs

저장 위치: server/training-data/ (gitignore 대상 — 데이터 별도 관리) 활성화: DIAMOND_TRAINING_CAPTURE=1 환경변수 (기본 off)

→ G13 확장: UnifiedTrainingRecord 스키마 통합으로 대체됨. 아래 참조.

[2026-04-14] G13-unified — UnifiedTrainingRecord: 전체 학습 데이터 파이프라인 통합

WHY:

기존 캡처 함수들이 파편화된 스키마로 각각 다른 파일에 저장:

captureTrainingPair() → pairs/{session}.jsonl (일반 LLM 호출)
captureDiamondNode() → diamond/nodes.jsonl (Diamond 도메인 에이전트)
captureScaffoldDPO() → dpo/scaffold-dpo.jsonl (스캐폴딩)

나중에 통합 학습 시 포맷 변환 작업 + 스키마 부채 발생 예방. 처음부터 task_type 레이블이 붙은 단일 포맷으로 통합.

통합 범위:

대상	task_type	이유
`TrainingPair`	`general_agent`	완전한 I/O 쌍 ✅
`DiamondNodeRecord`	`diamond_domain_agent`	완전한 I/O 쌍 ✅
`captureScaffoldDPO`	`scaffolding`	완전한 I/O 쌍 ✅
`DebateCapture`	유지	input 없음 — 마이그레이션 TODO
`PreferenceSignal`	유지	품질 신호 (I/O 쌍 아님)
`DiamondDebateRecord`	유지	debate 요약 (I/O 쌍 아님)

UnifiedTrainingRecord 스키마 (schema: '2'):

schema, record_id, captured_at, session_id, task_type, model, role?
system_prompt, user_message, raw_output (증류용 teacher I/O)
tokens_in?, tokens_out?, cost_usd?, latency_ms? (비용 추적)
quality: { outcome, score } (SFT 필터링)
context?: Record<string, unknown> (task_type별 추가 컨텍스트)

저장 구조:

pairs/{session_id}.jsonl — 기존 유지 (디버깅용)
unified/YYYY-MM-DD.jsonl — 신규 (날짜별 통합, 학습 데이터셋 빌드용)

quality.score 기준:

diamond active: 1 - (own_weaknesses / max(parent_weaknesses, 1)) (약점 감소율)
diamond pruned: 0.0
scaffold pass: 1.0 / fail: 0.0
general: 0.5 (unknown)

변경 파일:

server/src/orchestrator/training-capture.ts — UnifiedTrainingRecord + captureRecord() 추가, captureTrainingPair/captureDiamondNode/captureScaffoldDPO 내부 교체

구현 완료:

training-capture.ts: TaskType, QualityOutcome, UnifiedTrainingRecord 추가. captureRecord() universal writer (pairs/ + unified/ 동시 기록). captureTrainingPair(), captureDiamondNode(), captureScaffoldDPO() 내부 교체.
realtest-standard.md: Step 11 SSD 동기화에 unified/ + diamond/ 추가. 통합 학습 데이터 구조 표 추가.
callers 변경 없음 — 함수 시그니처 그대로 유지

저장 경로:

~/bigbossos-data/training/unified/YYYY-MM-DD.jsonl — 모든 I/O 쌍 통합 (학습 데이터셋 빌드용)
~/bigbossos-data/training/pairs/{session}.jsonl — 세션별 (디버깅용, 기존 유지)
~/bigbossos-data/diamond/debates.jsonl — Diamond 토론 요약 (플라이휠용)

[2026-04-14] Diamond Debate v8 — G10/G11/G12/G13 실측 결과 + G14 설계

v8 테스트 결과 (opus / Pool:3 / MaxLevel:12, training capture ON):

참고: v8은 Sonnet 주간 잔여 6% 상태에서 실행. 모델은 Sonnet(실행 시점에 opus 변경 전). v9부터 opus 적용.

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	✅탐색완료	⚠️비상탈출	⚠️비상탈출
레벨	6	12	12
노드	16	31	31
소요	544초	1124초	1132초
트레이드오프	0	3	3

총 비용: ~$4.79 (₩6,946)

버전별 전체 비교:

	v5	v6	v7	v8
T1	⚠️ 1434초	✅ 570초	✅ 529초	✅ 544초
T2	⚠️ 1212초	⚠️ 833초	✅ 706초	⚠️ 1124초 ← 퇴보
T3	✅ 733초*	⚠️ 912초	⚠️ 976초	⚠️ 1132초
비용	$5.37	$4.03	$3.79	$4.79
탐색완료	1/3	1/3	2/3	1/3

G10 효과 (MaxLevel 10→12):

T3: MaxLevel=12에서도 비상탈출 → G10으로 해결 안됨
약점 진동(3→4→2→2→3→3)으로 stallCount=1 달성 후 리셋 반복

G11 효과 (모델 기입):

테스트 보고서에 "실행 환경" 섹션 추가 (모델/Pool/MaxLevel 표)

G12 효과 (Ollama 연동):

ollama: prefix 라우팅 준비 완료. 실제 연결 테스트 미진행(모델 미다운로드)

G13 효과 (Training Capture):

[Training] debate 캡처: 8947c752... settled:false delta:3 (T2)
[Training] debate 캡처: c6f4e6e8... settled:false delta:1 (T3)
nodes.jsonl + debates.jsonl + unified/ 기록 확인 ✅

핵심 발견 — T2 퇴보 원인:

v7 T2: ✅탐색완료 L8 (약점 추이: 2→2→stall=2)
v8 T2: ⚠️비상탈출 L12 (약점 추이: 3→2→3→2→2→3)
원인: LLM 비결정론 — 동일 문제도 매 실행마다 약점 수가 달라짐. stallCount=2에 도달하기 전에 진동.
stallCount=1이 발동하더라도 다음 레벨에서 count가 바뀌면 stallCount=0 리셋 → G8 count-based stall의 구조적 한계 노출

신규 발견 — G8 stall detection 진동 취약성:

T2 약점 진동: 3→2→3→2→2→3 (stallCount 최대 1, 리셋 반복)
T3 약점 진동: 3→4→2→2→3→3 (stallCount 최대 1, 리셋 반복)
isStalled = currCount === prevCount 단순 비교 — 진동 패턴 탐지 불가
G8의 가정 "2회 연속 동일 = 정체"가 oscillation에 무효

[2026-04-14] G14 — No New Minimum 정체 감지 (진동 패턴 해소)

WHY:

v8 T2/T3 모두 ⚠️비상탈출. 원인은 약점 카운트 진동(oscillation). G8 count-based stall은 "2회 연속 동일"을 탐지하지만, 진동 패턴(2→3→2→3)에서는 stallCount가 1→0→1→0 반복.

근본 해결 — No New Minimum:

"역대 최솟값보다 더 줄어야 개선 중. N레벨 연속으로 새 최솟값 없음 = 탐색 완료."

지표	G8 (count-based stall)	G14 (no new minimum)
탐지 기준	2회 연속 동일 카운트	2레벨 연속 역대 최솟값 미달성
진동(2→3→2→3)	stallCount 리셋 → 탐지 불가	noNewMin 누적 → 탐지 가능
단조 감소	탐지 가능	탐지 가능 (개선 시 자동 리셋)

v8 데이터 검증:

T2 (3→2→3→2→2→3, allTimeMin=MAX_SAFE_INT 출발):
L1:3(newMin), L2:2(newMin), L3:3(noNewMin=1), L4:2(noNewMin=2) → 탐색완료 L4 ✅
T3 (3→4→2→2→3→3, 동일):
L1:3(newMin), L2:4(noNewMin=1), L3:2(newMin), L4:2(noNewMin=1), L5:3(noNewMin=2) → 탐색완료 L5 ✅
T1 (2→2): L1:2(newMin), L2:2(noNewMin=1), L3:2(noNewMin=2) → 탐색완료 L3 ✅ (기존과 동일)

구현:

diamond-debate.ts 변수 교체:
제거: prevWeaknessCount, stallCount, STALL_THRESHOLD, isStalled
추가: allTimeMinWeakness = Number.MAX_SAFE_INTEGER, noNewMinCount = 0, NO_NEW_MIN_THRESHOLD = 2
로그: [DiamondDebate] 정체 감지 noNewMin=N/2 (최솟값:M 현재:C)
탈출: noNewMinCount >= NO_NEW_MIN_THRESHOLD → 탐색완료

v9 예상:

T1: L3~L4 탐색완료 (기존 패턴 유지)
T2: L4~L6 탐색완료 (v8 비상탈출→자연종료, ~400초 절약 예상)
T3: L5~L7 탐색완료 (v8 비상탈출→자연종료, ~500초 절약 예상)

[2026-04-14] Diamond Debate v9 — G14 실측 결과 (최종)

v9 테스트 결과 (opus / Pool:3 / MaxLevel:12, training capture ON):

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	✅탐색완료	✅탐색완료	✅완전해결 (약점:0)
레벨	6	6	8
노드	16	16	21
소요	377초	358초	505초
트레이드오프	2	2	0

총 비용: $3.83 (₩5,554) — v8($4.79) 대비 -20%

버전별 전체 비교:

	v5	v6	v7	v8	v9
T1	⚠️ 1434초	✅ 570초	✅ 529초	✅ 544초	✅ 377초
T2	⚠️ 1212초	⚠️ 833초	✅ 706초	⚠️ 1124초	✅ 358초
T3	✅ 733초*	⚠️ 912초	⚠️ 976초	⚠️ 1132초	✅ 505초
비용	$5.37	$4.03	$3.79	$4.79	$3.83
탐색완료	1/3	1/3	2/3	1/3	3/3 ← 최초

*v5 T3는 허수 수렴 (G7-D 없이 긴 출력으로 약점 은폐)

G14 작동 확인:

T1: noNewMin=1/2(최솟값:2 현재:2) → noNewMin=2/2 → 탐색완료 L6
T2: noNewMin=1/2(최솟값:2 현재:2) → noNewMin=2/2 → 탐색완료 L6
T3: noNewMin=1/2(최솟값:2 현재:3) → L3 new min(1) → L4 약점:0 → 완전 해결 L8

T3 완전 해결 분석:

v5~v8: T3는 단 한번도 탐색완료 미달성 (v5는 허수 수렴)
v9: G14로 stall 탐지 + 도메인 에이전트가 L4에서 약점:0 달성
약점 추이: L1:2(newMin) → L2:3(noNewMin=1) → L3:1(newMin!) → L4:0(완전해결)
G14가 L2→L3 "증가→감소" 패턴에서 탐색을 중단하지 않고 계속 진행 → L4 완전 해결 가능

Training Capture 확인:

T3: settled:true delta:6 (초기 약점 6개 → 최종 0개, 완전 해결)

v9 총평:

3/3 탐색완료 최초 달성 (v5~v8: 최대 2/3)
T3 완전 해결(약점:0) 최초 달성 (v5~v8: 항상 트레이드오프 잔존)
총 소요 1240초 (v8: 2800초, -56%)
G14 "No New Minimum" — 진동(oscillation) 패턴 완전 해소, 단조 감소·상승 패턴 모두 처리

[2026-04-14] G15 — autoPrune 영구 미발동 구조 수정

WHY:

v5~v9 전 버전에서 폐기 노드가 항상 0건. autoPruneWeakNodes가 한 번도 발동하지 않음.

근본 원인 분석:

DOMAIN_AGENTS = ['tech', 'security', 'ux', 'cost']  // 4개
팬아웃: 1 active × 4 domain = 4 노드 생성
domainBest: tech 1개 + security 1개 + ux 1개 + cost 1개 = 4개 보존
pruneCandidates = [] (전부 domainBest에 흡수)
pruned = []  // 항상 비어있음 → autoPrune 영구 미발동

maxPrune이 1이더라도 pruneCandidates가 비어있으면 prune 불가. 도메인 다양성 보존 로직이 4도메인 = 4노드 구조를 전부 막아버림.

해결 — domainBest 보존 상한 제한:

const maxDomainBest = nodes.length - maxPrune;  // 최소 maxPrune개 pruning 보장
// domainBestCount < maxDomainBest 상한 추가

L1(nextLevel=1): cutRate=0 → maxPrune=0 → maxDomainBest=4 → 전부 보존 (영향 없음)
L3(nextLevel=3): cutRate=0.2 → maxPrune=0 → 영향 없음 (floor(4×0.2)=0)
L5(nextLevel=5): cutRate=0.4 → maxPrune=1 → maxDomainBest=3 → 1개 pruning 발동 가능
L7(nextLevel=7): cutRate=0.3(min cap) → maxPrune=1 → 동일

기대 효과:

v9 T3 L7(nextLevel=7) 팬아웃: cutRate=0.3 → maxPrune=1 → 약점 최다 노드 1개 pruning
고레벨에서 노드 수 자연 감소 → 토큰 절약 + Director 합성 부담 감소
도메인 다양성은 maxDomainBest 레벨에서 여전히 보장

구현 완료:

const maxDomainBest = nodes.length - maxPrune;
// domainBest.size < maxDomainBest 상한 추가

diamond-debate.ts autoPruneWeakNodes() — domainBest 루프에 && domainBest.size < maxDomainBest 조건 추가
L5+(nextLevel≥5)에서 maxPrune=1 → maxDomainBest=3 → 4노드 중 하위 1개 pruning 발동
L1~L3: maxPrune=0 → maxDomainBest=nodes.length → 기존 동작 그대로 (영향 없음)

v4 sonnet 3회 테스트 결과 (모델: sonnet / Pool:3 / MaxLevel:4):

	T1 (iOS 저장)	T2 (REST 인증)	T3 (실시간 채팅)
결과	❌ 오류 (타임아웃)	⚠️ 미수렴	⚠️ 미수렴
레벨	0	4	4
노드	0	11	11
폐기	0	0	0
소요	1432초	902초	966초
잔존약점	-	3개	2개

MVF 효과 평가:

MVF	효과	관찰
MVF-1 (`risk\	fix` 스키마)	✅ 효과 있음	잔존 약점이 구체적 아키텍처 문제 (DNS rebinding, timing leak, revocation 공백)
MVF-2 (intersection/per_node)	✅ 효과 있음	hybrid 강점 8개로 축소 유지 (level 3 노드는 11-13개)
MVF-3 (autoPrune)	⚠️ 미발동	`floor(4×20%)=0` — Pool:3/MaxLevel:4 파라미터에서 발동 불가 (5개 이상 필요)
converged 플래그	✅ 정상 작동	v3에서 성공으로 표시됐을 미수렴을 올바르게 노출

신규 발견 — G7: Sonnet 출력 폭발 → Director 타임아웃:

Sonnet이 haiku 대비 4-8배 큰 노드 출력 생성 (haiku: 3-8k자, sonnet: 15-32k자)
Level 3 노드 합계 ~76-100k자 → Director Level 4 hybridize 입력 과대
T1: 입력 ~100k자 → DIRECTOR_TIMEOUT_MS=20분 초과 → SIGTERM(code=143)
T2/T3: 입력 ~60-76k자 → 완료 (임계점 ~80-100k자 추정)
근본 원인: 노드 솔루션 출력 길이 제한 없음

G7 해결 방안 후보:

솔루션 최대 길이 제한 프롬프트 추가 ("500단어 이내")
Director 입력 전 솔루션 요약 단계 (요약 에이전트 추가 → 비용 증가)
Director 타임아웃 연장 (20분 → 40분) — 임시방편

G7 해결 결정 — A+B+C 하이브리드:

방안	구현 위치	역할
A. 프롬프트 길이 제한	`DOMAIN_OUTPUT_FORMAT`	"SOLUTION: 400단어 이내" 추가. 모델이 처음부터 짧게 작성하도록 유도
B. parseNodeOutput 하드 캡	`diamond-filter.ts`	solution 최대 2000자 하드 트런케이션 (B가 A의 단점 보완)
C. buildHybridizePrompt 노드 솔루션 제한	`diamond-filter.ts`	Director 입력 시 노드 solution 최대 1500자로 슬라이싱 (C가 B 트런케이션 발동 빈도 감소)

각 단점 상호 보완:

A 단점(모델 미준수) → B+C 백스톱
B 단점(중간 잘림) → A가 앞부분에 핵심 집중시킴
C 단점(리팩터링) → A가 실제 길이 줄여 발동 빈도 감소

구현 완료:

A: diamond-pool.ts DOMAIN_OUTPUT_FORMAT — "SOLUTION: 400 words MAX" 추가
B: diamond-filter.ts parseNodeOutput — SOLUTION_HARD_CAP=2000자 하드 트런케이션
C: diamond-filter.ts buildHybridizePrompt — HYBRID_SOLUTION_CAP=1500자 슬라이싱

G7 재테스트 결과 (sonnet / Pool:3 / MaxLevel:4):

	T1 (이전→G7)	T2 (이전→G7)	T3 (이전→G7)
결과	❌오류 → ⚠️미수렴	⚠️미수렴 → ⚠️미수렴	⚠️미수렴 → ⚠️미수렴
소요	1432초 → 407초	902초 → 379초	966초 → 506초
노드 출력 합계	~96k → ~13k (-86%)	~60k → ~10.5k (-83%)	~76k → ~9k (-88%)

G7 효과 확인:

T1 타임아웃 완전 해결 ✅ (SIGTERM → 정상 완료)
전체 평균 소요 -55% ✅
노드 출력 -83~88% ✅ (누적 복사 차단)
잔존 약점 품질 유지: 구체적 아키텍처 수준 (Redis fail-open DDoS 창, HMAC grace period gap, WAL 디스크 고갈 등)

여전히 미해결:

수렴 안됨 (converged:false 3/3) — MaxLevel=4 도달 시 약점 잔존
autoPrune 미발동 (floor(4×20%)=0)

신규 발견 — G7-D: Director 출력 폭발 (v5 테스트 중 발견):

v5 테스트(MaxLevel=10)에서 Director raw 출력이 레벨이 올라갈수록 폭발적으로 증가:

T1 Level	Director Raw 출력	G7-B 후 실사용	낭비
L2	8,692자	2,000자	77%
L4	13,470자	2,000자	85%
L6	20,759자	2,000자	90%
L8	19,516자	2,000자	90%
L10	27,589자	2,000자	93%

근본 원인: G7-A+B+C는 입력 눈덩이를 잡았지만, Director 템플릿에 출력 단어 제한이 없음.

Domain agent: DOMAIN_OUTPUT_FORMAT에 "400 words MAX" 강제 ← G7-A 적용됨
Director: (full solution text) — 제한 없음 ← 누락됐던 것

Monitor 600s 타임아웃 원인: 컨텍스트/토큰 문제가 아닌, L10 Director가 27k자 생성하는 데 수분 소요 → T1 1434초 걸림 → 10분 Monitor 자연 만료.

G7-D 해결 — Director 출력 캡:

diamond-pool.ts director 템플릿에 "500 words MAX" + RULES 섹션 추가 (Domain agent와 동일 패턴)
예상 효과: Director 출력 2,000-3,000자 수준으로 안정화 → G7-B truncation 발동 빈도 감소 → 전체 소요 -30~50% 추가 기대

구현 완료: diamond-pool.ts director 템플릿 — SOLUTION: 500 words MAX + RULES 블록 추가

[2026-04-14] Diamond Debate v4 — MVF 3종 구현 (3차 토론 최종 결론)

결정 배경 (1차→2차→3차 토론 결과):

1차: G1/G2/G3/G4 각 솔루션 제안
2차: 단점 발견 → 2차 솔루션 도출
3차 검증: 2차 솔루션도 임시방편 판정 (G2/G1은 방향 자체 틀림, G3/G4는 임시방편)
3차 토론: Critic Layer(근본 해결)는 sonnet 실측 전 도입 시 실패 원인 특정 불가 → MVF 3종 먼저

MVF 3종 (sonnet 테스트 전 최소 유효 수정):

#	문제	수정	근거
MVF-1	G1 도메인 leaf 편향	출력 스키마 `{risk, proposed_fix\	"unknown"}` 강제	역할 재정의: 발굴자→해결제안자. hallucination 방지
MVF-2	G3 MaxLevel 은폐 실패	Hybrid 약점 집합 `{intersection, per_node}` 분리 전달	공통 병목 vs 개별 실패 구분. false convergence 방지
MVF-3	G4 PRUNE 0회	autoPruneWeakNodes + node age 페널티 추가	LLM 보수성 제거, 오래된 노드 가치 하락 반영

미루는 것:

G2 참조(reference) 모델: 시그널 손실 가설 미검증
Critic Layer 전면 도입: 비용 +100%, isolation 불가
Adaptive MaxLevel: G1 풀리면 자연 감소 예상

Critic Layer 도입 트리거 (sonnet 2회 이상 실측 후):

강점 중복률 ≥ 30% 재발 (G2)
ux/cost 무한 약점 발굴 잔존 (G1)
leaf 사후 재검토 시 30% 이상 "조기 자체 종료" 판정

[2026-04-14] Diamond Debate v4 계획 — Opus 분석

Opus 총평: v3는 fast-path 추가(1/3 성공)와 finalValidation 오작동 차단이라는 실질 성과를 얻었으나 핵심 결함 3개 유지. v2가 "finalValidation이 거짓 PASS"였다면 v3는 "MaxLevel이 강제 PASS"로 병목이 이동했을 뿐. 수렴이 아니라 시간 만료다.

Opus가 도출한 구조적 문제 6개:

#	문제	심각도	근본 원인
G1	도메인 Leaf 편향 — tech/security 독점(6/6)	HIGH	도메인 간 약점 발굴 난이도 비대칭
G2	Level 3 강점 재폭발 — dedup 미작동(~14.8)	HIGH	paraphrase로 exact-match Set 우회, domain agent 프롬프트 독립적
G3	MaxLevel = 은폐된 실패 — 약점:3 강제 채택	HIGH	실패 경로 없음, converged 플래그 부재
G4	PRUNE 0회 — Director 구조적 보수성	MEDIUM	leaf만 리뷰 대상, T3는 leaf 0개라 Director 미발동
G5	약점 단조감소 미보장 — L3 security 약점:7(부모:3)	MEDIUM	부모 약점 해결 보고 스키마 없음
G6	Fast-path 우연성 — 결과 조건, 유도 메커니즘 없음	LOW	hybrid가 "평균 내기"이지 "약점 제거 지향" 아님

Opus 권고 수정 우선순위 (Codex 구현 대상):

P	수정	방식	예상 효과
P1-A	MaxLevel 도달 시 finalValidation 강제 + `converged` 플래그	코드 5줄 패치	거짓 성공 차단, 품질 지표 신뢰성
P1-B	강점 스키마 분리: `inherited_strengths` 코드 주입, LLM은 `new_strengths` 최대 2개만	파이프라인 스키마 변경	강점 14.8 → ≤10 예상, hybrid context 40% 감소
P2-A	부모 약점 해결 보고 스키마화: `resolved/deferred/new_issue` 태그 강제	스키마 + 파싱 변경	약점 단조감소 보장, MaxLevel 강제 0/3 예상
P2-B	결정론적 PRUNE 스코어: `score = new_strengths / (weaknesses+1)`, 하위 25% 컷 (도메인별 최소 1개 보존 제약)	코드 PRUNE 로직 교체	PRUNE 0 → 1~2회, 노드 11 → 8~9 예상
P3-A	도메인 leaf peer-review 훅: siblings OBSERVATIONS → 내 도메인 항목 자동 약점 격상	후처리 코드 훅	tech/security leaf 편향 완화, 비용 +25%
P3-B	hybrid "약점 제거 지향" 재작성: 남은 약점 중 critical 1개 명시 해결 강제	hybrid 프롬프트 수정	Fast-path 1/3 → 2/3 예상

Sonnet 테스트 전 필수 패치: P1-A + P1-B P1 패치 없이 sonnet 진입 시 수치 개선 착시 발생 (G2/G5는 자연 완화, G1/G3/G6은 구조 문제라 모델 무관).

[2026-04-14] Diamond Debate v3 — 4결함 수정 + 3회 테스트 완료

WHY (opus 토론 결과 반영):

결함 1 finalValidation 과잉: few-shot + fast-path skip + verdict OR 버그 수정 + 기본값 PASS
결함 2 강점 인플레이션: exact-match Set dedup + Director 8개 이내 재합성 지시
결함 3 PRUNE 0회: 3-condition 기준 명확화 + "3개+ 시 PRUNE 고려" 휴리스틱
결함 4 env 타이밍: 4개 lazy getter 통일 (getMaxLevel/getPoolSize/getDiamondModel/getDirectorModel)

v3 3회 테스트 결과 (haiku): | | T1 | T2 | T3 | |--|--|--|--| | 레벨 | 4 | 4 | 4 | | 노드 | 11 | 11 | 11 | | 폐기 | 0 | 0 | 0 | | 시간 | 424초 | 546초 | 429초 |

v2 → v3 개선 요약: | 지표 | v2 평균 | v3 실제 | |------|---------|---------| | 평균 레벨 | 5.3 | 4.0 (MaxLevel=4 lazy getter 수정) | | 평균 노드 | 14.7 | 11 | | finalValidation 발동 | 6/6 | 0 (fast-path/MaxLevel 우회) | | Fast-path 발동 | 0회 | 1회 (T1) | | PRUNE 발동 | 0회 | 0회 (haiku 보수성 유지) | | 평균 hybrid 강점 | ~35 | ~9 | | 평균 비용 | $1.14/회 | $0.60/회 (-47%) |

미달 항목:

레벨 4.0 > 목표 3: fast-path가 T1 1회만 발동, T2/T3는 MaxLevel 강제 수렴
PRUNE: haiku 보수성 해결 안 됨 — sonnet+ 또는 프롬프트 강화 필요
강점:16 이탈(T2 1회): 8-item 재서술 지시 미준수 — 프롬프트 강도 부족

[2026-04-14] Diamond Debate v2 — WEAKNESSES/OBSERVATIONS 분리 + 3회 테스트 ✅

WHY (토론 기반 설계 개선):

v1 3회 테스트에서 Director leaf review 미발동 (전 테스트 0건)
원인: 도메인 에이전트가 WEAKNESSES에 크로스도메인 문제까지 나열
security 에이전트가 "성능 오버헤드"를 weakness로 → 영원히 active
결과: leaf 0개 → Director leaf review 발동 기회 없음 → SPAWN/PRUNE 미발동
토론 결론: WEAKNESSES 필드가 두 가지 역할을 혼용
"내 도메인 기여 잔량 신호" vs "전역 문제 전달 채널"
분리 필요

결정 — WEAKNESSES/OBSERVATIONS 분리:

WEAKNESSES: 내 도메인 관점에서 아직 해결 못한 것만 (없으면 없음 → leaf)
OBSERVATIONS: 크로스도메인에서 발견한 것 — 다른 에이전트가 처리해야 할 사항
DB: diamond_nodes.observations TEXT[] 컬럼 추가 (migration 061)
buildFixAttemptPrompt: parentObservations 컨텍스트 주입
buildHybridizePrompt: observations 포함해 수렴 시 반영

v2 3회 테스트 결과: | | T1 | T2 | T3 | |--|--|--|--| | 레벨 | 6 | 4 | 6 | | 노드 | 16 | 11 | 17 | | 폐기 | 0 | 0 | 0 | | 시간 | 1018초 | 786초 | 1034초 |

검증된 것:

Director leaf review: 매 테스트 매 레벨 발동 ✅ (v1: 전혀 미발동)
ABSORB: 전 테스트 정상 동작 ✅
SPAWN: T3에서 최초 발동 ✅ (cedefe → SPAWN tech)
PRUNE: 0 (전 노드 강점 보유 — 폐기 없음)
v1 대비 노드 수 증가: leaf→ABSORB 경로로 더 깊이 탐색

[2026-04-13] Diamond Debate — Director 자율 Leaf 판단 (G-Diamond-4)

WHY:

현재 leaf 처리: 코드 기반 규칙 (findCrossBranchTarget/findCrossLevelTarget)
실전에서 leaf 발생 이유는 수십 가지 — 코드로 열거 불가

도메인 미스매치 (마케팅↔백엔드 영역 달라서 합의 불가)
도메인 소진 (UX weaknesses=0이지만 backend는 미해결)
기타 무수한 이유

weaknesses=0 = "내 도메인에서만 끝남"일 수 있음 — 전역 완료 아님
완전 자율화 원칙: Director AI가 전체 DAG 현황 보고 자율 판단

결정 — directorLeafReview() 도입:

각 레벨 종료 후 Director가 전체 노드 현황을 보고 leaf 처리 방식을 자율 결정
출력 포맷: LEAF_DECISION: {node_id} {ACTION} {args} | {reason}
ACTION 종류:
ABSORB {target_id} — 이 leaf 강점을 target 노드에 흡수 (cross 연결)
SPAWN {domain} — 이 leaf 기반으로 다른 도메인 관점 추가
PROMOTE — weaknesses=0이지만 사실 active (다른 도메인 미해결)
PRUNE — 진짜 영양가 없음, 완전 제거
findCrossBranchTarget/findCrossLevelTarget 하드코딩 제거

[2026-04-13] Diamond Debate 3차 테스트 ✅ PASS

결과:

총 레벨: 6, 총 노드: 16개 (폐기: 0)
Pool Worker 3개 고정으로 16노드 처리 (메모리 고정 ✅)
hybridize 정상 발동, finalValidation PASS ✅
최종 강점 39개, 약점 0개

검증된 것:

ViewHolder Pool 재사용 (Queue 대기 → Worker 재사용) ✅
fanout → hybridize → finalValidation FAIL → 재팬아웃 → PASS 전 흐름 ✅
haiku 모델로 완전 동작 확인

[2026-04-13] G-Diamond-3 — 도메인 에이전트 출력 포맷 누락 (노드 5개에서 멈춤)

WHY (1차 테스트 분석):

tech/security/ux/cost 에이전트 템플릿에 STRENGTHS:/WEAKNESSES:/SOLUTION: 출력 포맷 없음
haiku가 자유 형식으로 출력 → parseNodeOutput이 WEAKNESSES: 못 찾음 → 빈 배열
weaknesses.length === 0 → 전부 leaf → active 없음 → hybridize 스킵 → 1레벨로 종료
정상 흐름: level 1에서 각 도메인이 일부 약점 해결하되 새 약점도 남겨야 팬아웃 계속됨

수정:

diamond-pool.ts AGENT_TEMPLATES 도메인 에이전트 4종에 출력 포맷 추가
"자신의 개선안에도 해결 못한 약점을 솔직하게 보고하라" 명시

[2026-04-13] Diamond Debate 아키텍처 v2 — ViewHolder Pool + MVVM + Consigliere

WHY (DAG 원안의 구조적 한계):

Diamond Debate 원안: 각 노드마다 Claude CLI 프로세스 1개 spawn
DAG 팬아웃 특성상 노드 수 ≈ 레벨당 제곱 증가
결과: 동시 CLI 프로세스 수십 개 → RAM 폭발, macBook 환경 불가
추가 문제: Worker 재사용 시 이전 노드 컨텍스트 소실 → DAG 상태 관리 필요

결정 — 3-Layer 해결:

Layer 1: ViewHolder Pool (메모리 문제)

"에이전트 = CLI가 아니다. 에이전트 = 주입된 컨텍스트다"
CLI 프로세스 자체는 범용(generic). 고정 N개 Pool로 유지
bind(CLAUDE.md, memory.md, hard_rules, agent_template) 호출로 특수화
노드 수가 제곱으로 늘어도 CLI는 Pool 크기 고정

Layer 2: MVVM Input/Output Filter (컨텍스트 비용 문제)

Worker는 stateless — 이전 기억 없음
Input Filter: Consigliere에서 "이 노드에 필요한 것"만 꺼내 최소 주입
Output Filter: 출력 토큰 정제 후 Consigliere에 저장

Layer 3: Consigliere (DAG 상태 관리)

DAG 전체 상태의 single source of truth
노드 결과, 강점/약점, 간선, status 전부 저장
Worker가 다음 노드 처리 시 필요한 컨텍스트를 조회

흐름:

Node Queue → Pool에서 빈 Worker 선택
  → Input Filter(Consigliere 조회) → bind(context) → Worker 처리
  → Output Filter → Consigliere 저장
  → 다음 노드

구현 완료 (2026-04-13):

diamond-pool.ts — ViewHolder Pool (bind/release, POOL_SIZE=3)
diamond-filter.ts — Input/Output Filter (prompt 생성 + 출력 파싱)
diamond-dag.ts — DAG CRUD + cross 연결 탐색 (Supabase)
diamond-analyzer.ts — analyzeNode, evaluateNode
diamond-hybrid.ts — hybridizeNodes, finalValidation
diamond-debate.ts — 메인 엔진 (Queue + Dispatcher)
테스트 모델: DIAMOND_MODEL=haiku (기본값)
tsc --noEmit 에러 0건

[2026-04-10] G40 — parseDelegates agent_id 예약어 오인식 (3-Layer Atomic Fix)

WHY (실측062 결과 분석 + 토론):

실측062 cto/decisions.md 에서 CTO DELEGATE 출력 확인:

agent_id: (model=sonnet) cto_clone_1

버그 경로 (토론으로 확정):

agentIdKV = match(/^agent_id\s:\s(\S+)/) → (model=sonnet) 캡처
isValidId('(model=sonnet)') = false (괄호 포함) → 분기 탈락
colonIdx 분기: possibleId = 'agent_id' (콜론 앞 토큰)
isValidId('agent_id') = regex fallback /^[a-z][a-z0-9_]+$/ → true (매칭됨)
currentAgent = 'agent_id' ← 예약 키워드가 에이전트 ID로 오인식

근본 원인: agent_id 예약 키워드가 regex fallback에서 유효 ID로 인식됨
추가 구조 결함: colonIdx 분기에 예약어 블랙리스트 없음 → 역할:, model: 등도 같은 버그 잠재
cto_clone_1은 DB에 없는 동적 클론 → hiredAgentIds에 미포함 → regex fallback 경로만 사용
토론 결론: 3-Layer 동시 수정 (한 실측, 변수 1개)

Layer 구조:

Layer 1: agent_id: 전용 분기 신설 (parseInlineModel + split()[0] + continue)
Layer 2: colonIdx 예약어 블랙리스트 (agent_id, model, 역할, task, role)
Layer 3: model: 별도 키 인식 (프롬프트 권장 형식과 동기화, 기존 인라인도 계속 지원)

수정 완료:

llm.ts parseDelegates() 3-Layer 수정:
Layer 1: agentIdKV 정규식 (\S+) → (.+) 변경, parseInlineModel 적용 후 split(/\s+/)[0]으로 실제 ID 추출. continue로 colonIdx 분기 완전 차단
Layer 2: RESERVED_KEYS = Set(['agent_id', 'model', '역할', 'task', 'role', 'tasks']) 추가. colonIdx 분기 진입 전 블랙리스트 검사
Layer 3: model: sonnet 별도 키 인식 분기 추가 (currentAgent 존재 시 currentModel 갱신)
tsc --noEmit 타입 에러 없음 확인
실측063으로 검증 예정

[2026-04-10] G39 — 실측 소스 rsync 누락 (OpenSource→프로덕션 서버 미반영)

WHY (실측061 실측 중 발견):

G38 수정을 OpenSource 레포에만 적용, 프로덕션 서버(~/Desktop/bigbossos/server/)에 rsync 안 함
실측061 로그에서 "COO Phase B2: 3개" 확인 → 구 코드 레이블 → 수정 미반영 확인
realtest-standard.md Step 0.5에 server/src/ rsync 단계가 없었음

수정 완료:

realtest-standard.md Step 0.5에 TypeScript 소스 rsync 단계 추가 (G39 근본 해결)
실측061 spec-issuer.ts 수동 rsync + 서버 재시작 후 실측062로 검증

[2026-04-10] G38 — Phase B docQueue 순차 실행 (wbs/gantt/raci 독립 call)

WHY (실측060 + 토론 결과):

실측060에서 Phase B1 (wbs+gantt+raci) 5분 timeout 재현. console.warn 확인: spec-issuer LLM timeout (5분) x2
토론 결과: 주원인 = WBS+Gantt+RACI 출력 토큰 볼륨이 단일 5분 call 내 생성 불가. --effort high extended thinking이 가중 요인
안 3 (3개 병렬 독립 call) 검토: WBS/Gantt/RACI 일관성 파괴(각자 다른 태스크명 생성 가능), 동시 프로세스 4→8개(OOM 위험) 단점으로 탈락
최종 결정: docQueue 순차 실행. 문서 1개=1 call(1-2분 내 완료). wbs 결과를 gantt/raci 프롬프트에 주입해 일관성 보장. Phase B는 fire-and-forget이므로 순차 총 8-14분 소요는 유저 경험에 무영향

수정 완료:

spec-issuer.ts: callStatelessForDocs에서 --effort high 제거 (extended thinking 오버헤드 제거)
spec-issuer.ts: buildPhaseBPrompt(B1/B2) 제거 → buildSingleDocPrompt + getPhaseBDocQueue + docQueue 순차 루프로 교체
wbs 생성 완료 후 content를 wbsContent에 저장 → gantt/raci 프롬프트에 "참고 WBS" 블록으로 삽입 (태스크 일관성)
각 문서 개별 try/catch → 한 문서 실패해도 나머지 계속 진행
tsc --noEmit ✅

[2026-04-10] G36+G37 3차 수정 — SELF_DEBATE 경로 누락, migration DB 적용 누락

WHY (2차 토론 결과):

G36: clevel-director.ts systemRules 추가는 초기 DELEGATE 호출만 커버. SELF_DEBATE가 트리거되면 클론 태스크는 systemPrompt: identity(역할 설명만)를 사용하고, 합의 호출은 buildDebateSystemRules()(core+delegate만)를 사용 → 양쪽 모두 Capomastro 금지 없음. 클론이 Capomastro를 언급하면 합의 LLM이 그걸 채택할 수 있음.
G37: rsync로 SQL 파일 동기화는 했으나 DB 적용 명령 없음. 파일이 존재해도 Supabase에 migrate 안 하면 다음 실측에서도 테이블 없음.

수정 완료:

G36-클론: clevel-director.ts L137 systemPrompt: identity → systemRules. SELF_DEBATE 클론이 초기 호출과 동일한 Capomastro 금지 제약을 갖게 됨
G36-합의: debate-filter.ts RULE_BLOCKS.core에 ⛔ bin/Capomastro 절대 금지 추가. core는 모든 buildDebateSystemRules() 호출에 항상 포함 → 합의 호출 커버
G37: realtest-standard.md Step 0.5에 supabase db push 2>/dev/null || echo warn 추가. rsync(파일 동기화) + db push(DB 적용) 양쪽 모두 자동화. 실패 시 비차단
tsc --noEmit ✅

[2026-04-10] G35+G36+G37 진짜 근본 해결 (2차)

WHY (토론 결과):

G36: debate-filter.ts ios/android 규칙 수정은 헛방 — CTO 토론은 clevel-director.ts의 systemRules를 사용하며, 거기에 Capomastro 금지가 없음. clevel-director.ts에 직접 추가해야 함
G37: 파일 복사는 일회성 패치 — 다음 마이그레이션 추가 시 재발. Step 0.5에 rsync supabase/migrations/ 단계 추가해야 구조적으로 해결
G35: Phase B도 5~7개 문서를 단일 LLM 호출 — 여전히 timeout 가능. Phase B를 2개 병렬 서브 그룹으로 분리 (B1: wbs+gantt+raci, B2: risk+status+역할별)

[2026-04-10] G35+G36+G37 수정 — SpecIssuer timeout, Capomastro 재발, server_stats 마이그레이션

WHY:

G35: SpecIssuer가 CTO/COO 명세서 7개 문서를 단일 LLM 호출로 생성 → 5분 초과
G36: llm.ts Director 시스템 프롬프트에 (including Capomastro, mkdir, etc.) 예시가 남아있어 모델이 Capomastro를 유효한 bash 명령으로 인식, scaffold_agent 위임 지시에 삽입
G37: 052_server_stats.sql 마이그레이션이 REST 방식으로 실패했거나 migration_history에 기록됐으나 실제 테이블 미생성. StatsReporter가 30초마다 에러 로그 출력

수정 (근본 해결):

G35: spec-issuer.ts 단일 LLM 호출에 7~9개 문서 요청 → Phase A(spec+tasks, 5분, 동기)+Phase B(wbs/gantt/raci/risk/status+역할별, 비동기) 분리. 파이프라인 블로킹 없이 상세 문서 생성
G36: llm.ts Director ABSOLUTE RULE에서 Capomastro 예시 제거, HARD_RULES_DIRECTOR에 scaffold_agent Capomastro 금지 추가. debate-filter.ts ios/android 규칙에 Capomastro 호출 금지 명시 (CTO 토론 결과물 근본 차단)
G37: 실사용 인스턴스 supabase/migrations/ 052~058 파일 누락 확인. 파일 복사 + pg 직접 적용. stats-reporter.ts table not found → warn 레벨. migration 자동화 경로 동기화 완료
tsc --noEmit ✅

[2026-04-10] 6인 감사 체계 — Dario Amodei, Anthropic M&A 총괄, Sam Altman 추가

WHY: 기존 3인 감사(보안/빅데이터/회장대리)는 기술·데이터 관점에 편중. 외부 전략 관점(AI 안전성, 엑싯 가치, 시장 경쟁) 부재.

변경:

Step 9 "3인 감사" → "6인 감사"
추가 감사자:
#4 Dario Amodei (Anthropic CEO): AI 안전·정렬 관점. "이 시스템을 Anthropic이 배포해도 되는가"
#5 Anthropic M&A 총괄: 엑싯·기업가치 관점. IP/기술부채/모델종속성/인수자 리스크
#6 Sam Altman (OpenAI CEO): 경쟁·시장 관점. OpenAI 대비 차별점, 모델 락인 전략
감사 절차 9단계로 확장 (기존 6단계 + Dario/M&A/Sam 관점 3단계 추가)

[2026-04-10] 실측 디렉토리 규칙 변경 + Desktop 정리

WHY: Desktop에 archi_048 등 번호 폴더가 누적 생성되는 문제. 정리 기준 없이 산재.

변경:

실측 폴더 경로: ~/Desktop/archi_NNN → ~/Desktop/archi/실측테스트_NNN
archi 폴더가 영구 컨테이너 역할. Desktop 직접 생성 금지
.env PROJECT_DIR sed로 자동 갱신 (realtest-standard.md Step 3 재작성)
기존 archi_048, archi_049, archi_050, archi_053, archi_054, archi_055, archi_057, archi_ (=056) → ~/Desktop/archi/실측테스트_NNN/ 이동 완료
현재 회차(archi/{android,ios,docs,CLAUDE.md}) → 실측테스트_058/ 이동 완료
SSD /Volumes/SSD/bigbossos-training/realtest/실측테스트/ 백업 완료 (전 회차 rsync)

[2026-04-10] I10 소요시간 측정/표시 — session_stats 메시지 + iOS 카드

WHY: 파이프라인 소요 시간이 cost_logs/raw_metrics에만 저장되고 iOS에 전달되지 않았음. 1시간 이내가 바이럴 목표인데 유저가 실제 시간을 알 수 없는 상태.

구현:

index.ts: 파이프라인 완료 후 msg_type: 'session_stats' 메시지 → Supabase insert
content: elapsedSec, totalCostKRW, agentCount, targetSec(3600) JSON
SupabaseClient.swift: isSessionStats 프로퍼티 추가
ChatView.swift: session_stats 버블 → 소요시간/목표대비/비용/에이전트수 카드

[2026-04-10] R2 권한 격리 — pre-tool 훅 파일 타입 필터링 (재설계)

WHY (초안 문제): 첫 수정에서 C-Level roleAllowedTools의 Write/Edit를 제거했으나, C-Level도 명세서/ADR/상태보고 등 .md 문서는 직접 작성해야 함. Claude Code --allowedTools는 파일 타입 구분 없이 통째로 on/off → 블런트 차단은 잘못된 접근.

올바른 설계:

C-Level에 Write/Edit 복원 (.md 문서 작성 가능)
spawn 시 BIGBOSS_AGENT_ROLE=<role> env 추가
~/.claude/hooks/bigboss-role-guard.sh 글로벌 훅: C-Level 역할 + 코드 파일(.ts/.swift/.kt 등) → permissionDecision: deny
.md/.json 명세서는 통과

수정:

LEADER_ROLES에 cmo, cpo, ciso 추가 (유지)
roleAllowedTools C-Level Write/Edit 복원
callAgent() spawn env에 BIGBOSS_AGENT_ROLE 추가
~/.claude/settings.json PreToolUse 훅 등록
~/.claude/hooks/bigboss-role-guard.sh 생성
tsc --noEmit ✅
훅 시뮬레이션 5개 케이스 ✅ (워커 통과, C-Level+코드 deny, C-Level+.md 통과, 유저세션 통과, suffix_1 deny)

[2026-04-10] B1+C2-4 완료 — 팀 채팅 인증/API/Realtime + GameStatsBar 연동

FEAT-B1: 중앙 API 서버 (Supabase Auth + Vercel API + iOS 마이그레이션)

B1-1 ✅: 056_team_auth.sql — team_users 테이블 + RLS + auth.users FK
B1-2 ✅: /api/team/signup, /api/team/login — JWT Bearer 반환
B1-3 ✅: 057_team_chat.sql — team_rooms, team_messages, team_room_members (RLS: 룸 멤버만 접근)
B1-4 ✅: /api/team/rooms (GET/POST), /api/team/messages (GET/POST) — req.nextUrl.searchParams 사용 (Next.js 16 async-safe)
B1-5 ✅: TeamAPIClient.swift — Vercel API wrapper, JWT Bearer, SupabaseClient fallback
B1-6 ✅: /api/user/event + 058_user_events.sql — 이벤트 수집, ALLOWED_EVENT_TYPES, 1KB 제한
B1-7 ✅: RealtimeManager.swift — Phoenix Protocol WebSocket, 30s heartbeat, 자동 재연결. GroupChatView 3초 폴링 → Realtime 교체

FEAT-C2-4: iOS GameStatsBar 실서버 연동

/api/stats/progress (신규) — server_stats 싱글톤 row 조회, hasData 플래그 포함
TeamAPIClient.fetchProgress() + ServerStats Decodable 모델
SupabaseClient.fetchServerStats() — 미인증 fallback (anon key 직접 조회)
GameStatsViewModel — 60초 폴링, TeamAPIClient 우선 → SupabaseClient fallback
GameStatsBar — @StateObject vm 기반, RAM MB→GB 변환, onAppear/onDisappear polling 제어

수정 (기존 버그)

rooms/route.ts: .catch(() => {}) → Supabase builder에 .catch 없음, 제거

[2026-04-09] G33+G34 수정 — Android manifest icon, iOS ContentView 호환성

G33 ✅: writeAndroidScaffold() AndroidManifest에서 android:icon="@mipmap/ic_launcher" 제거 (mipmap 미생성 → AAPT 에러)
G34 ✅: writeIOSScaffold() ContentView.swift .foregroundStyle(.tint) (iOS 16+) → .foregroundColor(.accentColor) (iOS 14+) 교체, #Preview 제거
실측058에서 발견, 즉시 수정. 실측059 검증 예정

[2026-04-09] FEAT-A1 완료 — Capomastro 완전 제거 + GitHub 아카이브

writeIOSScaffold() ✅: 순수 TypeScript로 iOS 프로젝트 전체 생성 (pbxproj 템플릿 포함, 9개 파일)
syncXcodeProjectsTS() ✅: Capomastro 바이너리 없이 .swift 파일 → pbxproj 결정론적 UUID 기반 동기화
debate-filter.ts ✅: capomastroIos/capomastroAndroid 규칙 블록 제거, ScaffoldAgent 자동 처리 안내로 교체
llm.ts ✅: HARD_RULES_COMMON + HARD_RULES_DIRECTOR Capomastro 참조 제거
scaffolding-agent.ts ✅: scaffoldProject import 제거, Capomastro 폴백 제거
project-validator.ts ✅: scaffoldProject() deprecated (early return), CAPOMASTRO 상수 삭제, syncXcodeProjects() 완전 재구현
GitHub ✅: Lee-JuYeon/capomastro 레포 아카이브 완료
tsc --noEmit ✅

[2026-04-09] G30+G31+G32 해결 — 실측058 준비 완료

G30 ✅: writeAndroidScaffold() — TypeScript writeFileSync 직접 생성으로 교체. haiku Write도구 미호출 문제 근본 제거. 파일 14개 즉시 생성 보장
G31 ✅: llm.ts CTO 시스템 프롬프트 bin/Capomastro --platform android 제거 → ScaffoldAgent가 자동 처리함 문구로 교체. android_dev Capomastro 직접 호출 차단
G32 ✅: MIN_CODING_OUTPUT 체크에서 scaffolder 역할 면제. scaffolder는 Write 도구로 파일 생성하므로 텍스트 출력이 짧은 것이 정상
tsc --noEmit ✅, test-pipeline 32/32 ✅

[2026-04-09] 실측057 — FEAT-A1 에이전트 스캐폴딩 첫 검증

ScaffoldAgent ✅: android/api/ios 병렬 스캐폴딩 동작 확인 (18:33:20~18:34:41)
BuildValidator ❌: 미실행 — G30 등록 (ScaffoldAgent 경로 구조 불일치 추정)
G31: android_dev_1이 Capomastro 직접 3회 호출 — agent prompt 잔존 지침
G32: ScaffoldAgent haiku 과소출력 2회 재시도 (1000자 임계값 초과)
총 비용: $3.71 (5,376원), 소요: 21분 57초, 2라운드 필요

[2026-04-09] SSD 학습 데이터 이전 + DPO 캡처 추가

외장 SSD 마운트 확인: /Volumes/SSD (931GB, 743GB 여유)

폴더 구조:

/Volumes/SSD/
├── bigbossos-data/          ← 기존 ~/bigbossos-data/ 전체 이전 (13MB)
│   ├── training/pairs/      ← 에이전트 SFT 쌍
│   ├── training/debates/    ← 토론 데이터
│   └── training/signals/    ← 선호 신호
└── bigbossos-training/
    ├── sft/scaffold-sft.jsonl    ← opus 증류 (generate-scaffold-training-data.ts)
    ├── dpo/scaffold-dpo.jsonl    ← 빌드 성공/실패 DPO 쌍 (자동 누적)
    ├── models/                   ← 파인튜닝 완료 모델
    └── realtest/                 ← 실측 MD 29개 이전 완료

training-capture.ts: captureScaffoldDPO() 추가 — 빌드 pass/fail → chosen/rejected 자동 저장
training-capture.ts: DATA_ROOT /Volumes/SSD 자동 감지 (기존 코드 유지)
타입 체크: ✅

SSD: /Volumes/C.A.V.S.S M1/bigbossos-training/

sft/scaffold-sft.jsonl — opus 증류 데이터 (Stage 1)
dpo/scaffold-dpo.jsonl — 빌드 성공/실패 chosen/rejected 쌍 (Stage 2)
models/ — 파인튜닝 완료 모델 저장

Teacher=opus, Student목표=gemma3:4b LoRA

[2026-04-09] Capomastro 에이전트화 완료 (FEAT-A1)

WHY: Capomastro Go 템플릿 방식 → 새 도메인 추가 불가 + P/G 섹션 반복 버그 근원.

구현 완료:

server/src/orchestrator/scaffolding-agent.ts (신규): android/flutter/python/go/rust/ktor + generic
server/src/orchestrator/llm.ts: scaffolder role 추가 (Write,Edit,Bash)
server/src/index.ts: scaffoldProject() → await scaffoldProjectAgent() + Promise.allSettled 병렬
scripts/generate-scaffold-training-data.ts (신규): opus(teacher)→JSONL 증류 스크립트
.env.example: TRAINING_DATA_DIR, TEACHER_MODEL=opus 추가

설계:

android: 에이전트 전담. G29/P2 픽스 프롬프트 인코딩 → 재발 불가
ios: Capomastro 유지 (pbxproj + syncXcodeProjects 연동)
flutter/python/go/rust/ktor: 에이전트 전담 (신규 도메인)
Teacher=opus, Student목표=gemma3:4b LoRA. 데이터=SSD
타입 체크: ✅

[2026-04-09] 실측056 — G29+P2+G27 전부 해결 확인 ✅

G29 ✅: Android assembleDebug 성공. CLASSPATH 재배치 fix 정상 동작
P2 ✅: gradlew DEFAULT_JVM_OPTS 수정 후 JVM 오류 0건. APK 생성 완료
G27 ✅: iOS xcodebuild 통과 (ios_dev 2차 수정 패턴 — 스캐폴드 후 컴파일 에러 자동 수정)
미해결 이슈 0건 — P섹션/G섹션 전부 클리어

[2026-04-09] Capomastro 전면 재검토 + P2/G27 근본 수정

P2 (Capomastro 소스): android/template.go DEFAULT_JVM_OPTS '"-Xmx64m" "-Xms64m"' → "-Xmx64m -Xms64m". exec 방식에서 따옴표 리터럴 Java 전달 차단. 재빌드 + 배포
G27 (project-validator.ts): swiftCount < 3 → < 1. SwiftUI 초기 2파일로 sync 스킵되던 문제 수정
go.mod: 모듈명 ProjectBuilder → Capomastro, 전체 import 경로 업데이트
새 Capomastro 바이너리 (3.1MB) prod + OpenSource 양쪽 배포

[2026-04-09] G28 수정 + 실측053/054

G28 발견(053) + 즉시 수정: project-validator.ts CM_CANDIDATES에 bin/ProjectBuilder 경로 리네임 미반영 → Capomastro 못 찾음 → iOS/Android 스캐폴딩 + pbxproj 동기화 전부 스킵. 3줄 수정으로 해결
실측053 (4,389원): G28 발견. Validator 2건 에러. G26 정상 동작 확인
실측054 (2,237원): G28 ✅ 해결 확인. Capomastro 정상, iOS xcodebuild ✅, Validator ✅. P2(Gradle JVM) 재현. director_clone_1/designer_1 code=143 타임아웃
폴더 리네임 완료: /OpenSource/ledger→consigliere, ProjectBuilder→capomastro, projectmodel→soldato
실사용 인스턴스 리네임: ~/Desktop/cli-company→bigbossos, remote URL 업데이트

[2026-04-09] FEAT 마이페이지 + BUG-6 정리 + todolist 업데이트

iOS MyPageView.swift: Profile/Settings/Connection/About 4섹션. MainTabView 4번째 탭 추가
Android MyPageScreen.kt: 동일 기능. MainActivity 4번째 탭 추가
BUG-6: FCM 제거 완료로 firebase-service-account.json 불필요 → 해결
todolist: BUG 6건 전부 해결, FEAT MY-1~4 완료, I11 멀티룸 완료 반영
OfficeScreen.kt: @Composable 중복 어노테이션 버그 수정

[2026-04-09] G26 안 C 근본 해결 코드 적용

재위임 callClaude(-c) 완전 제거 → callAgent('evaluator') fresh 세션으로 교체
buildFactReport(): 코드 기반 팩트 보고서 (에이전트 수/파일 수/빌드 에러). LLM 호출 0, 수정 불가
모든 회장 메시지(1차/재위임 중간/재위임 최종)에 팩트 보고서 프리펜드
Evaluator 실패 시 graceful degradation: 팩트 보고서 + 원본 summary

[2026-04-09] 실측051 — G26 증상 해결 확인

비용: 3,971원 / 호출: 24건 / 에이전트: 6명
G26 ✅ 증상 해결: "최종 종합 보고 — StreamApp 빌드 라운드" 정상 출력 (거짓 "전 에이전트 실패" 사라짐)
소스 파일 14개 생성 (Swift 5, Kotlin 5, TS 3, SQL 1)
미해결: G27(iOS bundle executable, Capomastro), P2(Gradle JVM)
후속: 회장 판단으로 안 C(하이브리드) 근본 해결 진행

[2026-04-09] 실측050 + G26 추가 수정

실측050 결과

비용: 4,025원 / 시간: ~21분 / 호출: 24건 / 에이전트: 6명
SELF_DEBATE: 2 / Evaluator 재위임 발생 (2차 라운드)
파일 14개 실제 생성 (Swift 5, Kotlin 5, TS 3, SQL 1)
G26 재현: 최종 Director(-c)가 "전 에이전트 실행 불가" 거짓 판정
RLS ✅ / Consigliere ✅ / P2 재현 (Gradle JVM)

G26 추가 원인

summary 수정만으로는 불충분 — 최종 Director가 -c(세션 이어가기)로 호출되어 이전 에러 히스토리를 직접 보고 자체 판단
추가 수정: 최종 Director 호출 시 BuildValidator 결과를 함께 전달

[2026-04-09] BUG-7 해결 + 실측049

BUG-7: RLS FK 위반 근본 수정

RLS 검증 코드가 channel_id: '__rls_check__'로 messages INSERT → channels 테이블에 미존재 → FK 위반
INSERT 테스트 제거, messages + channels SELECT만으로 검증

실측049 결과

비용: 4,669원 / 시간: 32분 / 호출: 23건 / 에이전트: 6명
SELF_DEBATE: 2 (Director 클론 토론)
RLS 검증: ✅ FK 에러 없음
Consigliere 모순 감지: ✅ 거짓양성 0건 (BM25 only → check 스킵 정상)
iOS xcodebuild: ✅ 에러 0건
Android Gradle: ❌ P2 재현 ("-Xmx64m" ClassNotFoundException)
미해결 이슈: 0건

[2026-04-08] Consigliere BM25 거짓양성 근본 수정

문제

서버 시작 시 Consigliere 모순 감지(consigliereCheck)가 89건 거짓양성 출력
Ollama 미설치 → 시맨틱 임베딩 실패 → BM25 텍스트 매칭 폴백 → 단어 겹침만으로 전부 "모순" 판정

수정

consigliereEmbedded 플래그 추가: 임베딩 성공 여부 추적
initConsigliere(): 임베딩 실패 시(BM25 only) consigliereCheck() 스킵
BM25 검색은 유지 (검색과 모순 감지는 다른 문제)

[2026-04-08] Firebase/FCM 완전 제거

변경

server/src/orchestrator/fcm.ts 삭제 (188줄)
server/src/index.ts: FCM import, 초기화, 16개 notify 호출, shutdown 코드 전부 제거
server/src/setup.ts: Firebase service account 설정 단계 제거
server/src/orchestrator/debate.ts: notifyDebateStalled 제거
server/src/orchestrator/llm.ts: FCM 코멘트, notifyAlert 동적 import 제거
server/package.json: firebase-admin 의존성 제거
iOS(bigbossos-ios): Firebase SDK, GoogleService-Info.plist, aps-environment 제거
Android(bigbossos-android): Firebase SDK, google-services.json, FCMService.kt 제거
bin/guardian: FCM 코멘트 → 일반 "알림" 용어로 변경 (Supabase INSERT 방식 유지)

이유

각 유저가 개별 인스턴스를 소유하는 구조 → Firebase 프로젝트도 개별 발급 필요 → 셋업 복잡도 과다
현재 단계에서는 앱 활성 시 Supabase Realtime 알림으로 충분
배경 푸시(APNs/FCM)는 중앙서버(Cloudflare) 구축 후 재도입

[2026-04-08] 레포 분리 + Supabase 통일 + Vercel env 버그 수정

레포 분리

bigbossos 메인 레포에서 iOS/Android를 별도 레포로 분리 완료
bigbossos-ios: https://github.com/Lee-JuYeon/bigbossos-ios (로컬: ~/Desktop/Projects/OpenSource/bigbossos-ios)
bigbossos-android: https://github.com/Lee-JuYeon/bigbossos-android (로컬: ~/Desktop/Projects/OpenSource/bigbossos-android)
bigbossos 메인 레포 = server + dashboard + docs + scripts
대시보드(Vercel)는 유지 — 모바일↔Supabase 페어링 브릿지 역할

Supabase 통일

Supabase 프로젝트 1개로 통일: uvyivtjxmpkkduffbtnb (프로젝트명: bigboss_os_test)
구 프로젝트 wxxfegglpqsvjobzmrli 삭제

Vercel 환경변수 `\n` 버그 수정 (BUG-5)

Vercel env 재설정으로 개행 제거
iOS SupabaseClient.swift에 trim 방어 코드 추가 → 앱 크래시 근본 해결

Firebase 클라이언트 설정 git 포함

GoogleService-Info.plist (iOS), google-services.json (Android): 클라이언트 공개키이므로 git에 포함
firebase-service-account.json (서버 admin 비밀키): gitignore 유지. setup.js 처리 예정 (BUG-6)

[2026-04-08] R21 반복 에러 Top 10 룰 기반 자동 수정

변경

auto-fix.ts 신규: 5개 룰 (gradle_jvm, gradle_permission, ios_min_version, api_tsconfig, android_min_sdk)
index.ts: callAgentsParallel 완료 직후, BuildValidator 직전에 autoFixKnownErrors() 호출
raw_metrics에 자동 수정 결과 기록

대상 패턴

Gradle DEFAULT_JVM_OPTS 형식 오류 — sh 호환 형식으로 교정
gradlew 실행 권한 누락 — chmod 755
iOS IPHONEOS_DEPLOYMENT_TARGET — 회장 지정값으로 교정 (G19 근본 해결)
API tsconfig.json 누락 — 표준 tsconfig 자동 생성 (G21 근본 해결)
Android minSdk — 회장 지정값으로 교정

흐름

에이전트 병렬 완료 → autoFixKnownErrors() [0원] → BuildValidator → Evaluator

[2026-04-08] R24 시뮬레이터/에뮬레이터 실행 검증 (iOS만 완료, Android 미구현)

변경 (iOS)

project-validator.ts: simulatorRunIOS() + findAppBundle() + extractBundleId() + findAvailableSimulator() 추가
xcodebuild에 -derivedDataPath 고정 → .app 경로 확정
환경 실패(부팅/설치 불가)는 env 타입 스킵, 앱 크래시만 crash 에러로 반환
시뮬레이터 이미 Booted면 재부팅 안 함 (시간 절약)

흐름 (iOS)

xcodebuild 성공 → .app 탐색 → Bundle ID 추출 → 시뮬레이터 부팅 → 설치 → 실행 → 5초 생존 확인 → 셧다운

변경 (Android) — 2026-04-08 추가

project-validator.ts: emulatorRunAndroid() + findApk() + extractAndroidPackageName() + findOrCreateAvd() + waitForEmulatorBoot() + killEmulator() 추가
buildValidateAndroid(): compileDebugKotlin → assembleDebug 변경 (APK 생성 필요)
AVD 없으면 자동 생성 (system-images;android-34;google_apis;arm64-v8a)
에뮬레이터 화면이 회장에게 보임 (-no-window 안 씀)
환경 실패(부팅/설치 불가)는 env 타입 스킵, 앱 크래시만 에러로 반환

흐름 (Android)

assembleDebug 성공 → APK 탐색 → 패키지명 추출 → AVD 찾기/생성 → 에뮬레이터 부팅 → 부팅 대기 → 설치 → 실행 → 5초 생존 확인 → 종료

[2026-04-08] R17 의도→스펙 분해 품질 측정

변경

intent-quality.ts 신규: parseEvalBlock, serverVerifyItems, buildQualityReport, logIntentQuality, appendIntentMisses, buildDecompositionChecklist
llm.ts: EVALUATOR_SYSTEM_PROMPT [EVAL] 포맷 확장 (delegated/cause 필드 추가)
index.ts: Evaluator 후처리에 R17 분석 호출, Director 호출 전 decomChecklist 자동 주입

단점 보완 (토론 기반)

자연어 매칭 제거 → Evaluator가 delegated/cause 직접 분류 (코드 매칭 0)
Evaluator 오판 보정 → BuildValidator cross-check + 서버 Grep 재검증 3중 필터 (프롬프트 강화 제거)
자동 피드백 루프 → .consigliere/intent-misses.jsonl 축적 → buildDecompositionChecklist() Director에 자동 주입

[2026-04-08] C-Level Evaluator 확장 — 자율 개입

변경

llm.ts: C_LEVEL_EVAL_CONTEXT (6 C-Level별 평가 관점) + buildCLevelEvaluatorPrompt() 추가
index.ts: Evaluator 호출 시 getCLevelForAgent()로 에이전트별 C-Level 분류 → enriched prompt 사용
기존 EVALUATOR_SYSTEM_PROMPT 전체 유지, C-Level 컨텍스트는 추가 섹션으로만 주입

효과

에이전트 실패 시 해당 C-Level 도메인 전문성으로 원인 분석 (CTO→기술, COO→보안/운영, CFO→비용 등)
재위임 판단도 C-Level 관점 반영 → 같은 산하 적합 에이전트에게 정확한 재위임
R3(C-Level 헬스 모니터링) 대체: 별도 모니터 불필요, Evaluator 파이프라인에서 자연스럽게 처리

[2026-04-08] 합의 Director 타임아웃 근본 해결 + 실측050 통과

근본 원인

SELF_DEBATE 합의 시 compressOpinionForConsensus()가 raw 클론 출력 9-12K자를 그대로 전달
모델이 비구조화 입력에 thinking 8-27K자 소모 → 텍스트 출력 0자 (6회 연속 타임아웃)
debate.ts는 Output Filter → Consigliere → buildConsensusPrompt() ~3K 구조화 프롬프트 → 성공

해결

리더 합의 + SELF_DEBATE 합의 경로를 debate.ts 패턴으로 교체
parseOpinion() → DebateConsigliere → buildConsensusPrompt() → callDirectorStateless()
DEBATE_CONSENSUS_PROMPT에 OUTPUT FORMAT 제한 (3000자 이내, [DELEGATE] 중심)
gemma3:4b FILTER_TIMEOUT_MS 5초 → 15초

실측050 결과

합의 Director: thinking 6.4K+2.5K → text 11K+116K자 성공 (이전 0자)
원본 17K자 → 프롬프트 0.4K자 (97.6% 압축)
전체 파이프라인 완주, 워커 6/6 완료, 총 비용 3,846원

[2026-04-08] R2: 권한 격리

llm.ts: HARD_RULES_CLEVEL — C-Level/리더급은 코드 직접 작성 금지, DELEGATE 위임만
llm.ts: HARD_RULES_WORKER — 워커는 할당 범위만 수행, 설계 변경/아키텍처 결정 금지
getHardRules(): CTO → Director 규칙, 리더급(LEADER_ROLES) → CLEVEL 규칙, 워커 → WORKER 규칙 자동 분기

[2026-04-08] I75: C레벨 체제 문서 반영

workflow.md: 아키텍처, 에이전트 구성, 파이프라인 전면 갱신
구 구조(PM+CTO+16명) → C레벨 계층(CEO→CTO/COO/CFO/CMO/CPO/CISO→워커)
Phase 자동 판별, 시소 모델 가중치 표, Multi-C레벨 토론 흐름 추가
파이프라인: Phase 판별 → CTO 분석 → DELEGATE → C레벨 토론 → 워커 실행 → 검증 → CFO 분석
rules.md: I69~I75 회장 결정 로그 추가

[2026-04-08] I74: Multi-C레벨 토론

debate.ts: detectCLevelConflict() — DELEGATE가 2+ C레벨 산하에 걸치는지 판별
runCLevelDebate() — C레벨별 시스템 프롬프트로 관점별 의견 수집 → 합의 도출
C레벨 프롬프트: CTO(기술), COO(운영/보안), CFO(비용), CMO(시장), CPO(제품), CISO(보안감사)
index.ts: DELEGATE 확정 후 자동 트리거 → 합의에서 DELEGATE 재파싱 → 재조정 또는 기존 유지
기존 debate 인프라(Consigliere, NodeTree, callDirectorStateless) 재사용

[2026-04-08] I73: CFO 파이프라인

cfo-pipeline.ts: 세션 비용 분석 + 에이전트별 효율 분석 (LLM 호출 0회)
analyzeCosts(): 에이전트별 비용 비중, Top spender, 최근 평균 대비 비교
logCFOReport(): 콘솔 리포트 (회장 응답에는 미삽입 — 노이즈 방지)
getRecentCostLogs(): Supabase cost_logs 최근 N건 조회
scale/stable Phase에서만 활성 (C_LEVEL_REGISTRY activePhases 기반)

[2026-04-08] I71/I72: Phase 인식 + 시소 모델

I71: Phase 자동 판별

phase-detector.ts: 프로젝트 디렉토리 스캔 → mvp/scale/stable 자동 분류
시그널: iOS/Android 프로젝트, 빌드 산출물, 배포 설정, 마케팅 문서, 분석 설정 등
파이프라인 시작 시 Phase 감지 + 활성 C레벨 로깅

I72: 에이전트 비중 자동 조절 (시소 모델)

PHASE_PRIORITIES: Phase별 섹션 가중치 (0=비활성 ~ 3=높음)
buildPhaseContextBlock(): [PHASE_CONTEXT]...[/PHASE_CONTEXT] CTO 프롬프트 블록 생성
index.ts 3곳 주입: 리더 토론 태스크, CTO 단독 판단, SELF_DEBATE 클론 태스크
mvp: frontend/backend 집중, scale: 마케팅/배포 강화, stable: 보안/인프라/수익 중심

[2026-04-08] I69/I70: C레벨 체계 도입

변경

types/index.ts: CLevel, ProjectPhase, CLevelConfig, C_LEVEL_REGISTRY 타입 추가
sections.ts: 섹션에 cLevel 필드 추가, director→cto 리네이밍, support→finance/marketing/product 분리
llm.ts: DIRECTOR_MODEL→CTO_MODEL, isCTO() 하위호환 함수, C레벨 전원 HIGH_EFFORT
index.ts: director+cto 양쪽 인식, 로그 CTO로 표기

C레벨 구조

회장(유저) → CTO(기술) / COO(운영) / CFO(재무) / CMO(마케팅) / CPO(제품) / CISO(보안)
Phase별 활성 C레벨: MVP=CTO+COO, Scale+=CFO+CMO+CPO+CISO

[2026-04-07] 파싱 테스트 게이트: 실측 전 0원 검증 체계

근본 원인

P/G 이슈가 매번 재발하는 이유: 파싱 로직이 index.ts 1200줄 콜백 안에 인라인 → 단위 테스트 불가 → 5,000원 실측이 유일한 검증 수단
5인 토론 전원 동의, 단점 0개

해결

parseCEOMessage() 순수 함수 추출 → parser.ts
index.ts에서 parser.ts 호출로 교체
test-pipeline.ts 단위 테스트 (회장 메시지 파싱 5+ 케이스)
실측 절차에 테스트 게이트 추가

결과

parser.ts: parseCEOMessage() 순수 함수 (appName, appPkg, iosVersion, androidApi)
index.ts: 인라인 파싱 제거 → parseCEOMessage() 호출
test-pipeline.ts: 20건 테스트 전부 통과 (파싱 5종 + 보안 3종 + 회귀 12종)
realtest-standard.md: Step 2 테스트 게이트 추가
tsc --noEmit 통과

효과

실측 = "버그 찾기" → "완성품 검증"으로 전환
G8/G23급 파싱 버그는 0원에 발견
테스트가 project name: My-App_2 케이스에서 정규식 공백 처리 버그를 즉시 발견+수정 (실측 없이 0원)

[2026-04-07] G23 해결: 프로젝트명 파싱 정규식 수정

근본 원인

index.ts:1185 정규식 (\S+)가 쉼표/특수문자를 포함하여 매칭
회장 메시지 프로젝트명: StreamApp, 패키지: → StreamApp, 파싱
Capomastro가 StreamApp, 디렉토리 생성 → iOS/Android 전체 경로 오염

해결

(\S+) → ([A-Za-z0-9_-]+) (2곳)
5인 토론 전원 동의, 단점 0개

검증 (실측048)

✅ 성공 | 4,401원 | 27호출 | 25분 (047 대비 41% 절감)
G23 ✅: StreamApp 쉼표 없음 확인
G24 ✅: BuildValidator:iOS 호출됨 (Swift 2파일 파싱 성공)
P2 재현 (Gradle JVM 인프라 — 기존 이슈)

부수 효과

G24 연쇄 해결: 경로 정상화 → xcodebuild 정상 호출
보안: 경로 탐색/쉘 인젝션 벡터 원천 차단

[2026-04-07] 실측047: G23+G24 발견

결과

❌ 실패 | 7,474원 | 27호출 | 37분
SELF_DEBATE:3 + Evaluator ✅ + 6명 전원 완료

신규 이슈

G23: 프로젝트명 쉼표 혼입. Director가 "프로젝트명: StreamApp, 패키지:" 파싱 시 StreamApp, 생성. 전체 경로 오염 → iOS/Android 빌드 실패
G24: BuildValidator:iOS 미호출. API tsc만 실행됨. 쉼표 경로와 연관 가능

3인 감사

보안: RLS 검증 실패 로그, 페어링 코드 평문 기록
빅데이터: BuildValidator:iOS 데이터 결손, 에이전트 재시도 구조화 로깅 필요
회장대리: G23이 근본 원인. 모든 하위 문제(과소출력, 빌드 실패) 파생

[2026-04-07] I63-F: 토론 시스템 MVVM 마무리 (F1-F5 + B안 완료)

변경 사항

F1 (A안): parent_sequence 8곳 규칙 적용. append() forward reference validation 추가
B안: NodeTree → Consigliere read-only DAO 전환. 자체 상태 제거, 이중쓰기 제거
F2: checkConsensusGate() — bigram 유사도 80% 이상 시 Director 스킵 (비용 0)
F3: ParsedOpinion/ParsedConsensus에 dropped[] 필드. filter_log에 추출 실패 필드 기록
F4: enforceTokenBudget() — opinion 8K/consensus 12K hard limit + 경고
F5: FILTER_TIMEOUT_MS 환경변수 + gemma 응답시간 메트릭(ms) 로깅

아키텍처 확정

Consigliere = DB ("신", Single Source of Truth, append-only)
NodeTree = DAO (read-only, Consigliere 쿼리 메서드 모음)
debate.ts = ViewModel (Consigliere에 쓰기, NodeTree로 읽기)

파일

debate-consigliere.ts: append() validation, node_create 타입
node-tree.ts: 전면 재작성 → Consigliere DAO
debate.ts: parent_sequence 규칙, 이중쓰기 제거, 게이트 삽입
debate-filter.ts: 게이트 함수, dropped 추적, 토큰 예산, 타임아웃 설정

[2026-04-07] I63 실측 046: MVVM Debate 풀 파이프라인 실측 (Phase 1+2+3 통합)

목표

코드 레벨 검증(실측045) 이후 실제 Claude Code CLI 호출 포함 풀 파이프라인 동작 확인
Supabase 실 DB + Claude Code CLI + Ollama gemma3:4b 환경

결과: 성공 ✅

토론 주제: Netflix 클론 오프라인 캐싱 (CoreData vs Realm vs SQLite)
참여자: ios_dev_1, android_dev_1, db_dev_1 + biz_dev_1, designer_1, api_dev_1
1라운드 해결, Consigliere 21건, 9.4분, ₩1,917
Input Filter: opinion 225자, consensus 1,431자 (기존 -c 대비 99% 감소)
Dynamic Rules: 8블록 864자 (기존 대비 42% 축소)
callDirectorStateless: stateless -p, DELEGATE 4건 정상 파싱

I63 전체 완료 ✅

단계	실측	결과
Phase 1: Output Filter + Consigliere	실측044	11/11, ₩0
Phase 1+2+3: 코드 레벨	실측045	21/21, ₩0
풀 파이프라인 실전	실측046	성공, ₩1,917

[2026-04-07] I63 Phase 3 구현: 시스템 프롬프트 동적 선택

목표

토론 주제 + 참여 역할에 따라 관련 규칙만 Director에게 주입
기존 getHardRules('director') ~1,500자 → 동적 248-906자 (40-83% 축소)

변경

debate-filter.ts — buildDebateSystemRules() + RULE_BLOCKS + ROLE_RULES + TOPIC_RULES
llm.ts — callDirectorStateless()에 systemRulesOverride 파라미터 추가
debate.ts — buildConsensus에서 동적 규칙 생성 → callDirectorStateless 전달

실측 045: Phase 1+2+3 전체 검증 완료

21/21 통과, 0.7초, 비용 ₩0
설계 전용: 248자(~71tok), iOS 전용: 460자(~132tok), 전체: 906자(~259tok)

상태: 3 Phase 전체 완료 ✅

[2026-04-07] I63 Phase 2 구현: Input Filter + callDirectorStateless + `-c` 제거

목표

Consigliere에서 델타만 추출 → 최소 프롬프트 구성 (Input Filter)
Director 토론 합의를 -c 없이 fresh -p로 전환 (callDirectorStateless)
토큰 85-94% 절감 (2,683원 → ~400원 예상)

신규/수정 파일

debate-filter.ts — Input Filter 추가: buildOpinionPrompt, buildConsensusPrompt, estimateTokens
llm.ts — callDirectorStateless() + DEBATE_CONSENSUS_PROMPT 추가
debate.ts — collectOpinions/buildConsensus Input Filter 경유 + USE_CONSIGLIERE_INPUT 롤백 플래그

실측 045: Phase 2 자동화 검증 완료

16/16 통과, 4.2초, 비용 ₩0
Input Filter 프롬프트: opinion ~50-63tok, consensus ~127-144tok (기존 -c 41K-84K 대비 99% 감소)
effort:high 유지 확정

상태: Phase 2 완료 ✅ (풀 파이프라인 실측 대기)

[2026-04-07] I63 Phase 1 구현: Output Filter + DebateConsigliere 도입

목표

Agent 출력을 구조화 → Consigliere에 저장. -c는 아직 유지.
디버깅 개선 + Consigliere 데이터 축적 시작

신규 파일

server/src/orchestrator/debate-consigliere.ts — DebateConsigliere 클래스 (append-only log, sequence_number)
server/src/orchestrator/debate-filter.ts — Output Filter (parseDelegates 확장 80% + gemma3:4b 20%)

수정 파일

server/src/orchestrator/debate.ts — debateLoop에 Consigliere+Filter 연동

실측 044: Phase 1 자동화 검증 완료

11/11 통과, 5.0초, 비용 ₩0
DebateConsigliere CRUD + 트리 구조 + 요약 생성
Output Filter 정규식·gemma 폴백·DELEGATE 파싱
통합 플로우 1라운드 시뮬레이션
effort:high 토론 유지 확정 (스펙 반영)

상태: Phase 1 완료 ✅

[2026-04-07] 토론 MVVM 아키텍처 spec 문서 작성

docs/spec/debate-mvvm.md 신규 작성

2026-04-05 5인 전문가 패널 토론 전체 내용 기반
13개 섹션: 근본 문제(OOM 유사성) → MVVM 대응표 → 3개 레이어 상세 → Node Tree → 디버깅 → 동시성 → 멀티 CLI → R4 메모리 → 전문가 합의 → 3 Phase 마이그레이션
전체 아키텍처 다이어그램 + 호출 스택 + Ollama 타이밍 다이어그램 포함

회장 결정

Output Filter 모델: ~~haiku~~ → gemma3:4b (이미 Router에서 사용 중, 비용 0원)
마이그레이션: 3 Phase 점진적 (E 전문가 제안 채택)
DASHBOARD 빠른 링크에 debate-mvvm.md 추가

[2026-04-07] 부화장 SaaS 핵심 근거 보강

saas-incubator.md "1. 문제" 섹션 업데이트

SaaS 파편화를 부화장 도입의 #1 이유로 명시
현재 온보딩: Supabase/Vercel/Firebase 각각 회원가입 + CLI 다운로드 + 키값 설정 → 코드 작성까지 과정이 너무 길고 복잡
핵심: 결제(돈)와 직결되어 에이전트가 자율 처리 불가 → 회장 승인이 반복 호출됨
부화장 = 통합 플랫폼으로 회원가입 1번, 키 설정 0번, 회장 승인 최소화

[2026-04-05] I63 토론 파이프라인 분석 + Filter+Consigliere MVVM 아키텍처 설계

근본 원인 특정

-c 컨텍스트 누적: 합의 Director 호출 시 이전 대화 전체 재로딩 (85-94% 토큰 낭비)
effort: high: Director 호출당 6.6분 (회장 CLI 직접 사용 시 <2분)
시스템 프롬프트 반복: DIRECTOR_SYSTEM_PROMPT+HARD_RULES+HIRED_AGENTS 8.1K chars 매 호출

회장 설계: Filter + Consigliere MVVM

Agent (View) = 순수 베이스 모델, 템플릿 없음
Filter (Interface) = Input Filter (코드, 0원) + Output Filter (haiku/local, ~10원)
Consigliere (ViewModel) = 구조화 데이터 저장소, append-only log + sequence_number + parent_id
-c 완전 제거 → 항상 fresh -p 호출
예상 효과: 토론 비용 2,683원 → ~400원, 시간 22분 → ~6분

5인 전문가 패널 전원찬성 (프로젝트 최초)

분산 시스템, 컴파일러, ML, DevOps, 경제학 전문가 5명 만장일치

부수 발견

Multi-CLI 토론: Consigliere 스키마 = 통신 프로토콜 → Claude+Pizza+Codex 상호 토론 가능
R4 메모리 해법: 순차 모델 로딩 via Consigliere → 64GB→24GB (16GB도 가능 with LoRA)
Node Tree 구조: parent_id로 의견 갈래 분기 지원

반영 문서

todolist.md: I63 이슈, I-2-1 파이프라인 분석, I-2-2 전문가 토론, R4 실마리
DASHBOARD.md: 세션 기록

[2026-04-05] 회장 전략 결정: 대회 포맷 확장 — e스포츠 하이브리드 추가

기존 런닝머신 대회 + 신규 게임 대회 하이브리드 (LoL/발로란트/카스2)
포맷: BigBoss OS로 앱 빌드 시작 → 게임 대회 → 끝나면 프로젝트 확인
개발자 ∩ 게이머 교집합 활용, 스폰서 풀 확장 (게임사+주변기기+에너지드링크)
반영: business-model.md, roadmap.md, rules.md

[2026-04-05] 회장 전략 결정: 문서함 보안/에러 지식 DB + 보안 전문 에이전트 성장 파이프라인

배경

바이브코딩 = 생산성 ↑ + 보안/테스트 ↓ (테스트 코드 0개, 보안 대응 취약)
에이전트가 만든 코드의 보안 사고/에러/취약점을 기록하는 시스템 없음

회장 비전: SecurityConsigliere

문서함에 보안/에러 지식 카테고리 추가
프론트: 메모리 최적화, 비용 최소화, 로컬 DB 보안 등
백엔드: 보안키, 해킹 방어, 최적화, 비용 절감 등
각 사건마다: 공격/문제/에러 발생 경위 + 대처법 + 문제 코드 + 수정 코드 기록
빅데이터화 → 보안 전문 에이전트 학습 → 보안 전문가 회사급 AI로 성장
명세: docs/spec/security-consigliere.md

[2026-04-05] 외부 AI 리서치용 브리핑 문서 작성

Perplexity/ChatGPT에게 Phase별 광고 파트너 리서치 의뢰를 위한 브리핑 문서
BigBoss OS 개요, SaaS 부화장 모델, 광고 구조, Phase별 필요 파트너를 한 파일에 정리
위치: ~/Desktop/bigbossos-briefing.md

[2026-04-05] 회장 전략 결정: BigBoss OS SaaS "부화장" 모델

배경

서버/도메인/DB 초기비용조차 없는 '쌀먹' 유저가 타겟
Vercel/Supabase/Firebase처럼 BigBoss OS를 위한 BaaS(Backend as a Service)
멀게는 BigBoss OS OS를 위한 백엔드 SaaS

회장 비전: "인프라 부화장"

Firebase 모델: DB + 서버 + 에이전트 세션 + 빌드/검증 + 서브도메인 전부 무료 제공
졸업 모델: 유저 제품이 매출 발생 → 이용분만 소액 과금 → AWS/GCP 마이그레이션 지원 → 쿨하게 보내기
Anti Lock-in: Firebase/AWS는 나가기 어렵게 만듦. BigBoss OS는 나가기 쉽게 만듦
플라이휠: 졸업생 후기 → 신규 유입 → 반복

기존 SaaS와 차이

일반 SaaS: Lock-in → 비용 올리기 → 이탈 막기
BigBoss OS SaaS: 무료 입주 → 성장 지원 → 졸업 도움 → 재입주 루프

수익 구조

무료 입주 (쌀먹유저)
매출 발생 시 이용분만 소액 과금 (Usage-based)
졸업 마이그레이션 수수료 (소액 or 무료)
졸업생 입소문 → 신규 유입 (마케팅비 $0)

Phase 계획

Phase 1 (현재): 셀프호스트 오픈소스 + Stars/MAU 확보
Phase 2 (Stars 1K+): API 레이어 + 부화장 SaaS MVP
Phase 3 (MAU 5K+): BigBoss OS Cloud 정식
Phase 4 (멀게): BigBoss OS OS

[2026-04-05] 실측043: A/B 재실측 (빌드 검증 포함)

문제

실측042에서 빌드 검증 미실행 (ios_build_ok=null, android_build_ok=null)
원인: scaffoldProject('ios', ...) 호출이 index.ts에 완전 누락
Android/API/React/Web/Server/DB는 있으나 iOS만 빠짐
결과: ios/ 디렉토리 비어있음 → xcodeproj 없음 → BuildValidator 스킵

수정

index.ts에 iOS scaffoldProject 호출 추가
빌드 검증 포함 상태에서 A/B 테스트 재실행

A/B 테스트 결과 (빌드 검증 포함)

지표	토론 ON	토론 OFF
시간	40분	25분 (-39%)
비용	5,097원	7,840원 (+54%)
빌드	에러 1→재시도 성공	에러 1→재시도 성공
재위임	3명	6명

핵심 발견: 빌드 검증 포함 시 토론 OFF가 오히려 비쌈! 토론이 Director 판단 품질을 높여 재시도를 줄임.

[2026-04-05] Guardian — 서버 자동 감시/재시작 데몬 구현

bin/guardian watchdog 스크립트 생성
서버 spawn + 크래시 자동 재시작 (지수 백오프: 5→300초)
비활동 감지 (20분), 에러 루프 감지 (3회/5분)
FCM 회장 알림 (Supabase messages INSERT)
SSD 로그 자동 저장

[2026-04-04] Guardian — 서버 자동 감시/재시작 데몬

문제

회장이 모바일에서 메시지 → 서버 죽어있으면 응답 불가
실측042에서 프로세스 7시간 hang 경험
Claude Code 프로세스가 크래시/hang/OOM 시 수동 재시작 필요
외출 중이면 복구 불가능 — "혹시 살아있을까봐 기다림"

해결: `bin/guardian` 워치독 스크립트

서버 프로세스 spawn + 자동 감시
크래시 시 자동 재시작 (지수 백오프: 5→10→20→40초, 최대 5분)
무응답 감지: 서버 로그 출력이 N분 이상 없으면 강제 재시작
급속 크래시 루프 감지: 30초 내 재크래시 시 백오프 증가
재시작 시 회장 FCM 푸시 알림
모든 로그 SSD 자동 기록
사용법: node bin/guardian (npm start 대체)

[2026-04-04] SSD 데이터 자동 관리 (`/Volumes/SSD/bigbossos-data/`)

모든 실측/훈련 데이터를 SSD 전용 폴더에서 통합 관리:

training/ — Pizza 모델 훈련 데이터 (SFT pairs, debate clones, preference signals)
agent-logs/ — 에이전트 작업 로그 (.md) 장기 보관
cost-logs/ — 비용 로그 로컬 CSV 복제 (Supabase + 오프라인)
metrics/ — raw_metrics/messages JSONL 로컬 복제 + DB 스냅샷
metrics/sessions/ — 에이전트 대화 세션 전체 stream-json 기록 (RLHF용)
logs/ — 실측 서버 로그
realtest-reports/ — 실측 보고서 백업
builds/ — 빌드 산출물

코드 변경:

training-capture.ts: DATA_ROOT 상수 export. SSD 우선, 없으면 홈 폴백
supabase.ts: insertCostLog CSV 로컬 복제, insertMetric JSONL 로컬 복제
llm.ts: Director/Agent stdout 전체를 sessions/ JSONL로 기록
index.ts: console.log/error → SSD logs/server-YYYY-MM-DD.log 자동 기록
index.ts: 회장 "문서화 업뎃해줘" → bin/sync-ssd 자동 실행
bin/sync-ssd: 실측보고서/문서/에이전트로그/Supabase 스냅샷 → SSD 일괄 동기화

[2026-04-04] 실측042: I7 A/B 테스트 실측 + 에이전트 타임아웃

A/B 결과 (토론 ON vs OFF)

지표	토론 ON	토론 OFF	차이
소요 시간	32.5분	19.2분	-41%
비용	$3.99	$1.84	-54%
출력 토큰	183K	96K	-48%

버그 수정: 에이전트 무한 hang

callAgent/callClaude에 타임아웃 추가 (Director 15분, Director클론 10분, Worker 8분)
SIGTERM → 3초 후 SIGKILL 2단계 종료

훈련 데이터 수집 검증

SFT pairs: 871KB (5세션), Debate clones: 135KB (3건), Preference signals: 12KB (2세션) 정상 수집

[2026-04-04] I7: 오케스트레이션 A/B 테스트

AB_TEST_NO_DEBATE=true 환경변수로 리더 토론 + self-debate 스킵 모드
debate_rounds 추적: pipeline_run 메트릭에 토론 횟수 기록 (0=스킵, N=토론 N회)
051_ab_test_debate.sql: ab_debate_comparison(그룹별 성과), ab_debate_daily(일별 추세) VIEW
실측 방법: 같은 회장 요청을 (1) 기본 모드 (2) AB_TEST_NO_DEBATE=true로 2회 실행 → VIEW로 비교

[2026-04-04] I40: 세션 길이 / 재방문율 측정

session_end 이벤트 삽입 (finally 블록 — 성공/실패 모두 기록)
050_session_analytics.sql:
pipeline_session_lengths VIEW — 개별 파이프라인 소요시간
user_sessions VIEW — 30분 갭 기준 유저 사용 세션 (연속 메시지 = 1세션)
daily_session_stats VIEW — 일별 평균 세션 길이, 메시지 수
channel_return_rate VIEW — 채널별 재방문 빈도
get_public_metrics() 확장: avg_session_sec, avg_messages_per_session, return_channels

[2026-04-04] I55~I62: Pizza Model 훈련 데이터 수집 인프라

Phase 1: 인라인 캡처 (I55-I56)

training-capture.ts 신규 모듈: TrainingPair/DebateCapture/PreferenceSignal + fire-and-forget write queue
callClaude()/callAgent() 호출 완료 시 (system_prompt_full + input + output + tokens + cost) JSONL 자동 저장
.training/pairs/{session_id}.jsonl에 세션별 저장

Phase 2: Self-debate 원본 보존 (I57)

클론/리더 토론 원본 compressOpinionForConsensus() 전 .training/debates/에 저장
합의 후 DELEGATE 매칭으로 채택 클론 자동 마킹 (was_adopted)

Phase 3: 선호 신호 수집 (I58-I61)

빌드 pass/fail (confidence=1.0): iOS/Android/API 빌드 결과 → DPO 신호
Evaluator 재위임 + FIRE (0.85-0.9): rejected 에이전트 식별
회장 피드백 (0.9): alert_response 규칙 기반 분류 (승인/거부)
과소출력 retry (0.8): <1000자 원본 → retry_short rejected
.training/signals/{session_id}.jsonl에 저장

Phase 4: DB 마이그레이션 (I62)

049_training_signals.sql: 메타데이터 전용 (전문은 로컬 JSONL, Supabase 프리티어 보호)

[2026-04-04] P7 B안 근본 해결: Evaluator 전문 분리 저장

048_message_contents.sql: message_contents 테이블 신설 (TEXT 무제한)
insertMessageWithFullContent(): messages에 요약 INSERT → message_contents에 전문 저장
extractCEOSummary(): [EVAL] + 회장 보고서만 추출, [DELEGATE]/[FIRE]/[HIRE] 등 제거
messages.content 50K 제약 유지 (요약 전용), 기존 증상차단(95K truncate) → 안전장치로 격하
Evaluator 거치는 모든 경로(재위임/최종보고) 적용 완료

[2026-04-04] I49~I54: 메트릭 수집 강화 + 경량화 + 크론

I49 강화: metrics/NNN.md 신규 섹션

SELF_DEBATE 메트릭 (클론 수, 압축률, 합의 소요)
Evaluator 메트릭 (소요, 출력, H7 팀추천, 재위임)
H6 활동 이벤트 카운트
에이전트 출력 길이 + 과소출력 자동 감지 (< 1,000자 ⚠️)

I50 강화: raw/NNN.json 신규 필드

debate{}, evaluator{}, h6_events{}, output_chars

I51 강화: summary.md 추세 섹션

과소출력 경고 섹션, SELF_DEBATE/Evaluator 추세 섹션

I52: bin/metrics-cron

crontab 0 0 * 매일 자정 summary.md 재집계
raw JSON 기반, Supabase 독립

I53: 실측NNN.md 경량화

에이전트 상세 → metrics/ 링크로 대체
에이전트 테이블에 출력길이/비용 칼럼 추가

I54: form-template.md v3

3인 감사 결과 섹션 G (보안/빅데이터/회장대리 12기준)
SELF_DEBATE/Evaluator 섹션 D
회장 입력 3항목으로 축소

서버: Evaluator 타이밍 로그

[Server] ✅ Evaluator 평가 완료 (N초, N자) 로그 추가 → test-record 파싱 가능

[2026-04-04] 실측 상시 감시 체계 추가

realtest-standard.md Step 9에 3인 감사 체계 신설
보안 전문가: 코드·로그·로직 보안 허술점 전수 검사 → todolist 즉시 기재
빅데이터 전문가: 누락 메트릭·로그 사각지대 식별 → todolist 즉시 기재
회장 대리(Claude): 12가지 판단 기준 대조 → todolist 즉시 기재
기존 Step 9~10 → Step 10~11로 번호 조정

[2026-04-04] I39: DAU/MAU/리텐션 외부 공개 메트릭

047_public_metrics.sql — monthly_active_sessions VIEW + retention_cohorts VIEW
get_public_metrics() SECURITY DEFINER RPC — anon 호출 가능
반환 데이터: DAU/MAU/총세션/파이프라인실행/평균비용/평균소요/에이전트성공률/리텐션(D1/D7/D30)
호출 방법: supabase.rpc('get_public_metrics')

[2026-04-04] 성장 전략: 메트릭 수집 + PPL 확장 + 캐릭터 스킨 시스템

I45~I48: 자동 메트릭 수집 시스템

045_raw_metrics.sql — raw_metrics 테이블 + daily_active_sessions/agent_role_performance VIEW
서버 index.ts에 3가지 메트릭 자동 적재: session_start, pipeline_run, error
에이전트 태스크 완료 시 agent_task 이벤트 배치 INSERT
supabase.ts에 insertMetric()/insertMetrics() 함수 추가

I38-A~C: 프론트 데스크 PPL 광고 슬롯

iOS OfficeView + Android OfficeScreen에 🛎️ 프론트 데스크 오브젝트 추가
adBrand="LemonSqueezy" — 1인 개발자·스타트업 결제 솔루션 PPL
iOS: frontDesk 선택 → LemonSqueezy 소개 + 링크, Android: FrontDeskPanel composable

I-V4~V8: 캐릭터 레이어 구조 + 스킨 시스템

CharacterSkin 구조체/data class — Body/Tops/Bottoms/Shoes/Hair/Accessory 6레이어
iOS AgentSprite: 이모지 폴백 + 픽셀 레이어 합성 (ZStack)
Android: drawPixelCharacter() Canvas 렌더링 함수
046_character_skins.sql — character_skins + agent_skins 테이블 (시즌/브랜드/CDN, anon read)

[2026-04-04] I27~I30 법적 준수: AI 표시 + Apple/Google/EU 정책

I27: AI 생성 콘텐츠 표시

iOS ChatView, AgentChatView, GroupChatView — AI 메시지에 "AI" 배지 추가
Android AgentChatScreen, GroupChatScreen — 동일 "AI" 배지 추가
한국 AI 기본법(2026) + 앱스토어/플레이스토어 심사 요건 충족

I28: Apple Privacy Nutrition Label

PrivacyInfo.xcprivacy 생성 — OtherUserContent 데이터 수집 선언, 추적 비활성화
App Store Connect AI 기능 섹션은 배포 시 수동 기재 필요

I29: Google Play AI 콘텐츠 정책

AndroidManifest.xml에 com.google.android.apps.ai_generated 메타데이터 추가
Play Console Data Safety 폼은 배포 시 수동 선언 필요

I30: EU AI Act 적합성 검토

로컬 실행 도구 → 현재 범용 AI 모델 제공자(Anthropic) 의무 영역
EU 배포 시 적합성 선언서(DoC) + 기술 문서 준비 필요

[2026-04-04] I25~I26 보안: 프롬프트 인젝션 방어 + 에이전트 샌드박스

I25: 프롬프트 인젝션 방어

sanitizeCEOMessage() 함수 추가 (index.ts)
시스템 제어 태그([DELEGATE], [SELF_DEBATE], [ALERT], [FIRE], [HIRE], [MODIFY], [AGENT_CONFIG]) 전각 치환으로 무력화
system prompt:, ignore previous instructions 등 프롬프트 주입 패턴 차단
모든 회장 메시지→프롬프트 보간 지점 7곳에 적용: 리더 토론, Director 단독, SELF_DEBATE 클론, alert_response, 그룹 채팅, missing_info, Evaluator, generateAgentSpec

I26: 에이전트 실행 샌드박스

dev 역할(api_dev, ios_dev, android_dev 등 14개) null(전체 허용) → 'Read,Write,Edit,Glob,Grep,Bash' 명시적 도구 리스트
UI/UX 디자이너는 Bash 제외 (코드 생성 전용)
--dangerously-skip-permissions 완전 제거, 미등록 역할도 기본 도구 세트 적용
HARD_RULES_COMMON에 위험 명령 차단 규칙 추가: rm -rf, sudo, chmod 777, curl|sh, eval, exec 등

[2026-04-04] Android iOS 패리티 버그 수정

문제

SupabaseClient.kt: fetchMessages()/fetchAgentMessages()에서 sender_name 파싱 누락 → 단톡방 발신자 표시 불가
SupabaseClient.kt: createRoom()에서 사용하는 SimpleDateFormat/Locale/TimeZone import 누락 → 컴파일 에러
OfficeScreen.kt: 광고 배지 색상이 iOS(금색)와 불일치(빨간색)

수정

fetchMessages(), fetchAgentMessages()에 senderName 필드 파싱 추가
누락된 import 3개 추가
광고 배지 색상 금색(#FFD700)으로 iOS와 통일

[2026-04-04] F4 — 에이전트 AI 모델 동적 설정 + 승인 실행

문제

에이전트 모델(haiku/sonnet) 부적합 시 자동 업/다운그레이드 없음
재위임 시 같은 모델로 반복 → 같은 실패 반복 가능
H7 ALERT(해고/고용 추천) 회장 승인 시 실제 실행 안 됨

수정

Evaluator 프롬프트에 [MODIFY: agent_id, model=xxx, reason] 태그 추가
index.ts: [MODIFY] 파싱 → 🔧 모델 변경 회장 ALERT
승인 핸들러 추가: 회장이 '승인' → 최근 팀 구성 추천 ALERT 파싱 → 실행
FIRE → agents DELETE
MODIFY → agents.model UPDATE
실행 결과 채팅으로 확인 메시지
무시 → 회장 원래 프리셋 유지, 변경 없음

[2026-04-04] P4 — SELF_DEBATE 클론 비용 불균형 해결

문제

클론 출력 158K자 중 3K만 사용 (98% 폐기). 클론이 파이프라인 맥락(병렬 실행, 합의 추출)을 모름
"세세한 명세를 출력하라" 지시가 불필요한 장문 유발

수정

클론 태스크에 파이프라인 컨텍스트 추가: 클론 수, 합의 단계 핵심 추출, DELEGATE 집중
규칙/max_tokens 강제 아닌 정보 제공 → 클론이 자율적으로 출력 밀도 판단
회장 원칙: 하드코딩 금지 + 쓸 때는 확실하게 (효과 불명 지출 방지)

[2026-04-04] P3 — biz_dev 과소 출력 수정

문제

biz_dev 에이전트 출력이 656자에 불과 (설계 역할 기준 과소)
roleEffort 딕셔너리에 biz_dev 별칭 누락 → 'medium' fallback
DESIGN_ROLES에 포함되어 sonnet 모델 사용하지만 effort가 'medium' → 모순

수정

llm.ts roleEffort: biz_dev, db_dev, app_sec, db_sec 별칭 추가
business_logic_developer, database_developer, dba effort를 'medium' → 'high'로 승격 (DESIGN_ROLES 판단 역할에 맞게)

[2026-04-04] P2 — Android Gradle JVM 인프라 오류 수정

문제

gradlew DEFAULT_JVM_OPTS="-Xmx64m -Xms64m" (쌍따옴표 감싼 단일 문자열) → 일부 sh 환경에서 Could not find or load main class "-Xmx64m" 에러
eval 시 따옴표가 리터럴로 전달되어 Java가 클래스명으로 인식

수정

project-validator.ts: buildValidateAndroid()에서 gradlew 실행 전 DEFAULT_JVM_OPTS 패치 로직 추가. "-Xmx64m -Xms64m" → '"-Xmx64m" "-Xms64m"' (Gradle 8.x 표준 형식)
android/gradlew: 워크스페이스 gradlew도 동일 패치 적용

[2026-04-04] I19~I24 — 팀 단톡방 (그룹 채팅)

구현

I19 DB: rooms, room_members 테이블, messages.sender_name 컬럼, generate_room_code() 함수 (043_team_rooms.sql)
I20 서버: room_ 채널 감지 → @디렉터/@director 멘션 시 Director 자동 응답. 멘션 없으면 개입 안 함
I21 iOS RoomListView: Rooms 탭 추가. 방 생성(6자리 코드, 1시간 만료) + 코드로 참가 + 방 목록 폴링
I22 iOS GroupChatView: sender_name 표시, Director 응답 구분 표시, 멤버 목록/퇴장 기능
I23 Android RoomListScreen: iOS와 동일. Rooms 탭 추가, 다크 테마
I24 Android GroupChatScreen: iOS와 동일. sender_name, Director 구분, 멤버/퇴장
SupabaseClient 양 플랫폼: createRoom, joinRoomByCode, fetchRooms, fetchRoomMessages, sendRoomMessage, leaveRoom, fetchRoomMembers
ChatMessage 모델: sender_name 필드 추가 (iOS + Android + Server types)

[2026-04-04] Office 회장 캐릭터 이동 + 점프 + 사다리 + 아랫점프

결정

회장 캐릭터에 메이플스토리 스타일 물리 엔진 적용
회장 지시: 사다리 위치에서 조이스틱 위/아래로 사다리 타기, 점프, 아랫점프 구현

구현

회장 위치가 맵 좌표 기반 (기존: 화면 중앙 고정)
��력 + 플랫폼 충돌: 바닥에 착지, 공중에서 떨어짐
조이스틱 좌우: 회장 캐릭터 좌우 이동, 카메라 자동 추적
사다리: ��다리 근처에서 조이스틱 상/하 → 사다리 타고 층간 이동
점프 버튼: 일반 점프 (바닥에서만)
아랫점프: 2층에서 조이스틱 아래 + 점프 → 2층 플랫폼 통과해서 1층으로 낙하
iOS + Android 동시 구현

[2026-04-04] Office UI 사이드뷰 전환 (메이플스토리 모티브)

결정

Office 탭 탑뷰 → 사이드뷰(메이플스토리 스타일) 전환
회장 지시: 기능 유지, UI만 사이드뷰로 변경
2층 구조 + 중앙 사다리로 층간 이동
iOS + Android 동시 구현

구조

2층: 업무공간(에이전트 책상), 회의실(좌), 서버실(우)
1층: 휴게실(냉장고, 자판기, 에어컨, 커피머신, 노트북, 문서함, 휴지통)
중앙 사다리(🪜): 탭하면 1층↔2층 전환
하늘 배경 + 구름 + 달 (메이플 밤하늘)
조이스틱: 좌우 스크롤 + 사다리 근처 상하 이동
모든 기존 기능 유지: 광고 슬롯, selection, 탭 액션

[2026-04-04] H7 — Director 고용/해고 추천

문제

작업 완료 후 불필요한 에이전트/필요한 역할 식별 방법 없음

수정

Evaluator 프롬프트에 [FIRE: agent_id, reason] / [HIRE: role, reason] 태그 문법 추가
index.ts: Evaluator 응답에서 정규식 파싱 → 회장 ALERT (승인/무시 옵션)
FCM 알림 동시 발송

파일

server/src/orchestrator/llm.ts (EVALUATOR_SYSTEM_PROMPT)
server/src/index.ts (H7 파싱 + ALERT)

[2026-04-04] H6 — 에이전트 상태 실시간 표시

문제

회장 모바일에서 실행 중인 에이전트 상태 확인 불가 (로그만 가능)

수정

에이전트 시작 시 agent_id='activity' JSON 메시지 INSERT: { type: 'agents_started', agents: [...], total, startedAt }
에이전트 개별 완료 시 { type: 'agent_done', agentId, status, elapsedSec } INSERT
회장 모바일은 Realtime으로 agent_id='activity' 메시지 구독하여 실시간 표시

파일

server/src/index.ts

[2026-04-04] H5 — 회장→특정 에이전트 직접 지시

문제

회장이 특정 에이전트에 직접 지시할 방법 없음 → 항상 Director 경유 필수

수정

회장 메시지 멘션 파싱: "ios_dev에게: ...", "@android_dev_1 ...", "ios_dev_1에게 ..." 패턴
매칭된 에이전트에 callAgent() 직접 전달 (Director 우회)
에이전트 ID 완전 매칭 + prefix 매칭 + role 매칭 지원
Director는 직접 지시 대상 제외
비용 로그(F6) 포함

파일

server/src/index.ts

[2026-04-04] P5 — test-record Supabase sync 수정

문제

bin/test-record에서 dotenv 패키지 import 실패 → Supabase INSERT 불가
원인: bin/은 루트에서 실행되나 dotenv는 server/node_modules에만 존재

수정

dotenv 동적 import 제거 → .env 직접 파싱 (readFileSync + regex)
@supabase/supabase-js를 createRequire(server/package.json)으로 로드
외부 의존성 0개로 동작

파일

bin/test-record

[2026-04-04] P1 — 합의 Director 소요 시간 단축

문제

클론/리더 출력 전체(~300K자)를 합의 컨텍스트로 넘김 → 27분 소요 (실측 37)
합의 Director에게 필요한 건 DELEGATE 블록 + 기술 결정뿐인데 서술까지 전부 포함

수정

compressOpinionForConsensus() 함수 추가
DELEGATE 블록 전체 추출 (정규식 2패턴: 멀티라인 + 인라인)
기술 스택 키워드 추출 (17개 키워드)
섹션 헤더 요약
에이전트당 최대 3000자 캡
리더 토론 합의 + 자기복제 합의 양쪽 적용
원본 → 압축 크기 로깅 (비교 추적)
예상 효과: 300K자 → ~10K자 입력, 합의 시간 27분 → ~5분

파일

server/src/index.ts

[2026-04-04] F7 — setup.ts 원클릭 풀 셋업 개선

문제

Supabase 연결 검증 없이 .env만 저장 → 잘못된 키로 서버 시작 시 런타임 에러
마이그레이션 적용 안내 없음 → 신규 유저 DB 스키마 누락
Firebase 서비스 계정 안내 없음

수정

STEP 7 추가: Supabase REST API 연결 테스트 (5초 timeout)
마이그레이션 자동 적용: supabase CLI 감지 시 supabase db push 제안, 미설치 시 대시보드 안내
STEP 8 추가: Firebase 서비스 계정 안내 (FCM 푸시용, 선택)
최종 검증에 'Supabase 연결' 항목 추가 (9개 체크 → 8개 체크)
9단계 구조로 재편: 1.Node → 2.npm → 3.Claude → 4.Ollama → 5.모델 → 6.env → 7.DB연결+마이그레이션 → 8.Firebase → 9.최종검증

파일

server/src/setup.ts

[2026-04-04] F6 — 에이전트별/요청별 비용 대시보드

문제

토큰 비용이 콘솔 로그에만 출력됨 → 회장 모바일에서 비용 확인 불가
에이전트별 비용 분포 파악 불가 → 비효율 에이전트 식별 어려움

수정

cost_logs 테이블 신설 (042_cost_logs.sql)
요청별: channel_id, 회장 메시지, 총 비용(USD/KRW), 총 토큰, 소요 시간
에이전트별: JSONB array로 caller, inputTokens, outputTokens, costUSD, costKRW
cost_summary VIEW: 총 요청, 총 비용, 평균 비용, 오늘/이번주/7일평균
supabase.ts: insertCostLog() 함수 추가
index.ts: 요청 완료 시 getTokenSummary() → insertCostLog() 비동기 저장
anon SELECT 허용 → 회장 모바일 앱에서 읽기 가능

파일

supabase/migrations/042_cost_logs.sql
server/src/orchestrator/supabase.ts
server/src/index.ts

[2026-04-04] F3 — FCM 유형별 디바운스 차등

문제

모든 푸시 알림이 동일 30초 디바운스 → ALERT 지연, 토론 알림 과다

수정

ALERT (확인 필요) = 즉시 전송 (0초)
완료 알림 = 30초 디바운스
토론 알림 = 60초 디바운스
getDebounceMs() + isDuplicate() 리팩토링, 최대 디바운스(60초) 기준 캐시 정리

파일

server/src/orchestrator/fcm.ts: 디바운스 로직 차등화

[2026-04-04] F2 — Consigliere 재인덱싱 + 임베딩 타이밍 개선

문제

consigliereEmbed()가 서버 시작 시에만 호출 → 에이전트가 생성한 새 파일의 시맨틱 임베딩이 갱신 안 됨
재인덱싱이 동기 호출이라 에이전트 결과 처리 지연 가능

수정

callAgentsParallel() 완료 후 consigliereEmbed() 비동기 호출 추가
index + embed를 fire-and-forget 백그라운드로 전환 (에이전트 결과 처리 비차단)

[2026-04-04] E5 Phase 1 — Evaluator 세션 분리 (Generator/Evaluator 구조적 분리)

결정

종합 Director를 새 세션 Evaluator로 분리 (GAN 영감 Generate-Verify 패턴)
회장 토론 기반 결정: 안 A(LLM Evaluator) + 안 B(코드 기반) + 안 C(Director 종합) 합체

설계

기존 종합 callClaude의 channel_id를 새로 발급 → 별도 세션 → 앵커링 편향 제거
Evaluator 입력: 회장 원문 + DELEGATE 명세서 + BuildValidator 결과 + 에이전트 결과 요약
평가 방식: 체크리스트 대조 (기능별 ✅/❌ + 확신도 HIGH/LOW)
확신도 HIGH 누락 → 자동 [DELEGATE] 재위임, LOW → 회장 ALERT
재위임 후 Evaluator 재실행 없음 (MAX_EVAL_ROUNDS=1), BuildValidator만 재실행
Evaluator 도구: Read, Grep, Glob (읽기 전용)
Evaluator 모델: sonnet (판단 역할)
에러 시 graceful degradation: 기존 summary 그대로 회장 전달
기존 종합 대체이므로 추가 비용 ~0원

약점 보완

같은 모델 편향 → 체크리스트 대조로 구조화 (열린 평가 아닌 사실 확인)
컨텍스트 상실 → 회장 원문 + DELEGATE 명세만 선별 주입 (팀 구성 이유 불필요)
Evaluator 오판 → 확신도 기반 분기 (LOW면 회장 질문)
실측 근거 부재 → 실측 40을 E5 검증 실측으로 설계
재위임 루프 → MAX_EVAL_ROUNDS=1 구조적 차단

구현 완료

server/src/orchestrator/llm.ts:
EVALUATOR_SYSTEM_PROMPT 추가 + export
'evaluator' → roleAllowedTools: 'Read,Grep,Glob' (읽기 전용)
'evaluator' → roleEffort: 'high'
'evaluator' → DESIGN_ROLES (sonnet 할당)
server/src/index.ts:
종합 Director → Evaluator callAgent 전환 (새 세션 evalAgentId)
회장 원문 + DELEGATE 명세 + BuildValidator 결과 + 에이전트 결과 주입
try/catch graceful degradation
재위임 후 Evaluator 재실행 없음 (MAX_EVAL_ROUNDS=1 주석)
delegates 타입에 model 추가 (E8 누락 수정)
TypeScript 컴파일 에러 0건

[2026-04-03] P2 수정 — Android Gradle 시작 실패 거짓 통과 방지

문제

실측 37: Could not find or load main class "-Xmx64m" — Gradle JVM 시작 실패
buildValidateAndroid()가 .kt 에러 패턴만 파싱 → 0건 → ✅ 거짓 통과
Gradle이 실행조차 안 됐는데 "Android 빌드 성공" 표시

원인

Gradle 시작 실패(JVM 오류, ClassNotFoundException 등)와 컴파일 에러 0건을 구분 안 함
에이전트가 생성한 gradlew에서 JVM 옵션(-Xmx64m)이 클래스명으로 전달되는 스크립트 버그 가능성

수정

buildValidateAndroid(): Gradle 시작 실패 패턴 감지 후 인프라 에러로 추가 (거짓 통과 방지)
Could not find or load main class, ClassNotFoundException, Error: Unable to access jarfile 감지
server/src/orchestrator/project-validator.ts

[2026-04-04] E8 — Director DELEGATE 인라인 모델 지정

결정

Director가 DELEGATE에서 에이전트별 모델을 직접 지정 가능
형식: ios_dev_1: (model=haiku) Swift UI 구현
우선순위: DELEGATE 인라인 > [AGENT_CONFIG] > DB agents.model > DESIGN_ROLES fallback
DESIGN_ROLES는 Director가 지정 안 할 때만 fallback

변경

server/src/orchestrator/llm.ts — parseDelegates() 반환 타입에 model?: string 추가. (model=xxx) 파싱 로직 추가.
server/src/index.ts — tasks 빌드 시 d.model 최상위 우선순위로 추가
Director 시스템 프롬프트에 모델 지정 문법 안내 추가

[2026-04-03] 회장 결정 — 모델 선택은 Director가 해야 함

결정

역할→모델 고정 매핑(DESIGN_ROLES)은 임시 구조. 근본적으로는 Director가 작업 복잡도 보고 에이전트별 모델을 결정해야 함
biz_dev DESIGN_ROLES 원복 (sonnet) — 임시 유지, Director 모델 자율 판단 구현 전까지
todolist에 E8로 추가: Director DELEGATE에서 모델 지정 가능하도록

[2026-04-03] 모델 정책 확정 — 리더급 sonnet, 몽키코더 haiku

결정

Director + 리더급(DESIGN_ROLES) 전부 sonnet 고정 (당분간)
몽키코더(코딩 역할) 전부 haiku — biz_dev 포함
opus는 회장 DB 오버라이드 시에만 사용

변경

server/src/orchestrator/llm.ts — DIRECTOR_MODEL = 'sonnet'. DESIGN_ROLES에서 biz_dev 제거.
코드 주석 업데이트

[2026-04-03] 실측 38 준비 — biz_dev DESIGN_ROLES 제거 (haiku 전환)

결정

business_logic_developer / biz_dev 를 DESIGN_ROLES에서 제거 → haiku로 전환
실측 37에서 biz_dev_1이 sonnet 사용(656자 과소 출력). 설계 역할이 아닌 코딩 역할로 재분류.
진짜 DESIGN_ROLES: architect, cto, designer, security, pm 등 판단/설계 전용 역할만 유지
비용 효과: biz_dev sonnet(~75원) → haiku 전환 시 절감 기대

변경

server/src/orchestrator/llm.ts — DESIGN_ROLES에서 business_logic_developer, biz_dev 제거

[2026-04-03] E3/E6/E7 — 아키텍처 철학 정립 + Router 제거

결정

Router 완전 제거: gemma3:4b(Ollama) 포맷 변환 레이어 삭제. parseDelegates() 직접 파싱 → 실패 시 Director 재시도 1회. "프롬프트보다 구조적 시스템" 원칙 적용.
Director 항상 먼저: 회장 메시지 → Director(Opus) 팀 구성 판단이 항상 첫 단계. Router가 먼저 가로채는 구조 제거.
도구 품질 > 오케스트레이션: rules.md에 원칙 문서화. Consigliere/Capomastro 고도화가 오케스트레이션 추가보다 우선.
HARD_RULES 정리: 죽은 [DEBATE] 태그 제거. Consigliere 조건부 주입(50자 이상일 때만).

변경

server/src/index.ts — Router 호출 블록 제거, Director 재시도로 교체. routeDirective import 제거.
server/src/orchestrator/llm.ts — ROUTER_SYSTEM_PROMPT 역할 변경 기록. HARD_RULES_COMMON [DEBATE] 태그 제거. Consigliere 조건부 주입.
docs/rules.md — 도구품질/Director먼저/리더급토론 원칙 3개 추가.
docs/strategy/architecture-vision.md — 전체 구조도 수정 (Router 위치, HIRE/FIRE 단계, 리더급 중간검토 추가).
docs/todolist.md — 아키텍처 비전 다이어그램 추가.

[2026-04-03] E4 — 리더급 에이전트 토론 시스템 재설계

결정

리더급 기준: model='opus' AND DESIGN_ROLES (둘 다 충족해야 진짜 리더)
리더 2명 이상: 실제 멀티 리더 토론 → 세세한 명세서 → 몽키코더 전달
리더 1명: 자기복제 [SELF_DEBATE: N]으로 대체
토론 결과물 = 명세서 (코드 품질 토론 아님, 설계/아키텍처 토론)
debate.ts 몽키코더 간 토론 로직 제거, index.ts 리더 토론으로 교체

변경

server/src/index.ts — 고용 에이전트에서 리더급 필터링 (opus + DESIGN_ROLES)
server/src/index.ts — 리더 2명↑ 실제 토론 / 1명 자기복제 분기
server/src/orchestrator/llm.ts — LEADER_ROLES 상수 추가

[2026-04-03] E4 — 토론 시스템 제거

결정

근본 원인(BUILD_SUCCESS 텍스트 파싱)이 G16에서 이미 해결됨
BuildValidator(구조적 컴파일 검증) + Director(Opus, 판단력)가 역할 완전 대체
기술 충돌 감지 → 토론 큐 등록 로직도 제거 (Director가 판단)
debate.ts import 제거, activeProcesses는 llm.ts 직접 참조로 교체

변경

server/src/index.ts — requestDebate/processNextDebate/getDebateQueueStatus/setCeoInfiniteMode import 제거
server/src/index.ts — 기술 충돌 토론 큐 등록 블록 제거
server/src/index.ts — 토론 큐 처리 블록 제거
server/src/index.ts — gracefulShutdown/killActiveAgents의 activeProcesses 참조를 llm.ts로 이전

[2026-04-03] E1/E2 — Director(Opus 4.6) 자율 판단 + 자기복제 토론

결정

Director 모델: sonnet → opus (판단력 최대화)
자기복제 트리거: 서버 "5명 이상" 하드코딩 → Director가 [SELF_DEBATE: N] 출력
복제 수: 서버 고정 2명 → Director가 N 지정
복잡도 판단: 서버 코드 → Director 본인 판단
임시 Director DB upsert 방식 → 메모리 복제로 교체

변경

server/src/orchestrator/llm.ts — Director 모델 opus 고정, SELF_DEBATE 파서 추가
server/src/index.ts — 서버측 복잡도/복제 판단 로직 제거, [SELF_DEBATE: N] 실행기로 교체
server/src/orchestrator/llm.ts — DIRECTOR_SYSTEM_PROMPT 자율 판단 권한 명시

[2026-04-03] E1 — 작업 비례 에이전트 수 (복잡도 3단계 분류)

결정

Router 프롬프트에 복잡도 3단계 규칙 추가 (코드 변경 없음, 프롬프트 수정)
간단(2명) / 보통(4명) / 복잡(6명) 기준 명문화
기대 효과: 간단 요청 비용 -50%

변경

server/src/orchestrator/llm.ts — ROUTER_SYSTEM_PROMPT 복잡도 분류 규칙 추가

[2026-04-03] A5 — 출력 파싱 강화 (parseDelegates 대시 형식 + 0건 재시도)

결정

케이스 1: - ios_dev_1 - task 대시 분리 형식 추가
케이스 4: parseDelegates 0건 시 Router에 포맷 교정 요청 재시도 1회

변경

server/src/orchestrator/llm.ts — parseDelegates() 대시 분리 형식 파싱 추가
server/src/index.ts — Router 0건 결과 시 재시도 로직 추가

[2026-04-03] A4 — 프로세스 내결함성 (work_state 기반 자동 재개)

결정

안 B+: messages.work_state JSONB 컬럼 1개 추가 (새 테이블 없음)
서버 시작 시 status='running' 감지 → 완료된 에이전트 제외 후 자동 재실행
회장 개입 없음 (기준 12: 완전 자동화 달성)

변경

supabase/migrations/041_work_state.sql — messages.work_state JSONB 컬럼 추가
server/src/index.ts — 작업 시작/에이전트 완료/완료 시 work_state DB 동기화
server/src/index.ts — 서버 시작 시 running 감지 → agents_remaining 자동 재실행
server/src/index.ts — 재개 시 회장 FCM 알림 ("이전 작업 자동 재개")

[2026-04-03] I9/F7 — 원클릭 5분 온보딩 (setup.ts 전면 재작성)

변경

server/src/setup.ts 전면 재작성 (126줄 → 230줄)
7단계 자동화:

Node.js 버전 체크 (18+ 강제)
npm install 자동 실행 (node_modules 없을 때)
Claude CLI 설치 확인 + 자동 설치 (npm install -g @anthropic-ai/claude-code)
Ollama 설치 (macOS=brew, Linux=curl sh, Windows=winget)
Ollama 서버 자동 기동 + 필수 모델 pull (gemma3:4b, nomic-embed-text)
.env 대화형 설정 (SUPABASE_URL/ANON_KEY/SERVICE_ROLE_KEY/PROJECT_DIR/APPLE_TEAM_ID)
최종 검증 7항목 체크리스트 + 소요 시간 측정

버그 수정: .env에 SUPABASE_KEY → SUPABASE_SERVICE_ROLE_KEY 올바른 변수명
신규: PROJECT_DIR 설정 (기본값: ~/Desktop/projects)
신규: Apple Team ID keychain 자동 감지 (macOS)
신규: 소요 시간 출력 ("5분 이내" 달성 여부 표시)

[2026-04-03] I5 — iOS BuildValidator xcodebuild 2단계 추가

변경

buildValidateIOS() 2단계로 확장
1단계: swiftc -parse (기존, ~1초, SDK 불필요)
2단계: xcodebuild build -sdk iphonesimulator (신규, ~5분, 실제 컴파일)
swiftc -parse 실패 시 2단계 스킵 (불필요한 xcodebuild 방지)
xcodebuild 없는 환경 자동 감지 → 스킵 (graceful)
xcodeproj 없는 환경 자동 감지 → 스킵
로그 태그: [BuildValidator:iOS:xcode]
CODE_SIGNING_REQUIRED=NO, ONLY_ACTIVE_ARCH=NO 설정 (로컬 서명 불필요)

효과

Android(compileDebugKotlin) + API(tsc --noEmit) + iOS(xcodebuild) 대칭 완성
swiftc -parse ✅인데 실제 컴파일 실패하는 케이스 감지 가능

[2026-04-03] bin/test-record — 4문서 자동 생성 + 토큰 추세 분석

추가

docs/realtest/metrics/NNN.md 자동 생성 (에이전트별 토큰/비용/소요시간)
docs/realtest/metrics/raw/NNN.json 자동 생성 (구조화된 raw 데이터)
docs/realtest/metrics/summary.md 자동 갱신 (누적 집계)
비용 추세 (최근 10회 평균 + ↑↓→ 방향)
에이전트별 토큰 소모 평균 (전체 누적, 역할별)
히스토리 테이블에 입력/출력 토큰 열 추가
parseLog() 강화: 에이전트별 latency/토큰/비용, Kotlin 파일 수, 총 토큰, 파이프라인 시각

[2026-04-03] H3 구현 — 작업 중 수정 요청 → 에이전트 재실행

구현

server/src/index.ts INTERVENTION 블록에 H3 케이스 추가
수정 키워드 감지: 말고/대신/바꿔/수정해/변경해/다시 해/고쳐/틀렸어/잘못됐/아니야/아니고
H4(전면 취소)와 H2(큐 적재) 사이 새 분기
SIGTERM 로직을 killActiveAgents(tag) 헬퍼로 추출 (H3/H4 공유)
H3 flow: SIGTERM → activeWork/workQueue 초기화 → fall-through → 수정 지시로 새 워크플로우 실행

[2026-04-03] G22 근본 해결 — Go embed 번들링

문제

Capomastro copyGradleWrapperJar()가 외부 환경 캐시에 의존 → 환경마다 결과 다름

근본 원인 (5 Whys)

Capomastro → ~/.gradle 캐시 탐색 → 없으면 경고만 → 외부 환경 가정이 근본 원인

수정

Capomastro/internal/generator/android/assets/gradle-wrapper.jar 번들 추가
//go:embed assets/gradle-wrapper.jar → 바이너리에 포함
환경 탐색 로직 50줄 → os.WriteFile(dest, gradleWrapperJarData, 0644) 1줄로 교체
Capomastro 재빌드 (3.1MB, +52KB) → bin/Capomastro 배포

효과

어떤 환경에서도 gradle-wrapper.jar 항상 존재
G14 실질 피해(gradlew 실패 → 에러 루프)도 함께 제거

[2026-04-03] 실측 034 — ✅ 성공 + G22/G14b 해결

항목	결과
BuildValidator iOS/Android/API	✅ 전부 에러 0건
G22	✅ gradle-wrapper.jar 생성 (Unity 경로 폴백)
G14b	✅ gradlew 없음 (2차 라운드 AGENT_SPEC 주입)
gracefulShutdown B2	✅ SIGTERM 정상 동작
비용	6,720원 (실측 33 대비 -23%)

수정 내용

G22 Capomastro/generator/android/generator.go: copyGradleWrapperJar() Unity/Android Studio 경로 폴백 추가 → 재빌드
G14b index.ts summaryDelegates tasks2 생성 시 generateAgentSpec() 주입

[2026-04-03] 실측 033 — ⚠️ 부분 성공

항목	결과
6/6 에이전트	✅
iOS BuildValidator	✅ 101 Swift 에러 0건
API BuildValidator	✅ 3 TS 에러 0건
Android BuildValidator	❌ gradle-wrapper.jar 없음 (G22)
G15/minVersion	✅
H1/H2/H4	✅ 코드 탑재 확인
비용	8,695원

신규 이슈: G22(gradle-wrapper.jar 미생성), G14b(2차 라운드 AGENT_SPEC 미주입)

[2026-04-03] H섹션 H1/H2/H4 — 완료

#	기능	파일
H1	작업 중 새 명세 요청 감지 + 긴급도 분류	index.ts
H2	추가 요청 WorkQueue 적재 + 완료 후 자동 실행	index.ts
H4	전면 취소 + 에이전트 SIGTERM/SIGKILL	index.ts

구현 내용

workQueue: Map<projectId, WorkItem[]> + activeWork: Map<projectId, ActiveWork> — I11/I17: projectId 기준 격리
H1 alert_response 제외. 회장 채널 메시지만 처리(I15). 키워드 기반 분류(비용 0, I6 준수)
H2 큐 적재 → finally 블록에서 완료 후 DB re-insert → Realtime 자동 트리거로 재실행
H4 "취소/중단/멈춰/처음부터/스톱" 키워드 → activeProcesses SIGTERM → 3초 SIGKILL → 큐 비우기 → activeWork 해제

빌드: npm run build → 에러 0건

[2026-04-03] D섹션 (D1~D3) — 완료

#	문제	파일
D1	FCM setInterval 셧다운 미해제	fcm.ts, index.ts
D2	debate.ts 동적 import 실패 무시	debate.ts
D3	토큰 비용 역산 부정확	검토 결과 이미 정확 — 변경 없음

구현 내용

D1 fcm.ts fcmCleanupInterval 변수 + shutdownFCM() export. index.ts gracefulShutdown에서 shutdownFCM() 호출
D2 debate.ts Consigliere import catch에 console.warn 추가 (나머지 try/catch는 이미 로깅 중)
D3 검토: total_cost_usd 직접 사용 + result 이벤트 usage.input_tokens 직접 읽기 — 이미 정확한 구조. 추가 변경 불필요

빌드: npm run build → 에러 0건

[2026-04-03] C섹션 안정성 개선 (C2~C8) — 완료

#	문제	파일
C2	Consigliere serve 레이스 컨디션	consigliere.ts
C3	워처 구독 미해제/재연결 없음	llm.ts
C4	writeFileSync 타임아웃 없음	debate.ts, llm.ts
C5	토론 재귀 깊이 무제한	debate.ts
C6	임시 Director DB 미정리	index.ts
C7	에이전트 동시 spawn 무제한	llm.ts
C8	세션 Map 메모리 릭	llm.ts

구현 내용

C2 consigliere.ts serve 시작 후 포트 7891 준비 대기 (500ms×10회 retry)
C3 llm.ts getWatcherChannel: CLOSED/ERROR 시 unsubscribe + 재구독
C4 llm.ts writeFileSync → import('fs/promises').then(writeFile) / debate.ts await writeFile
C5 debate.ts MAX_DEBATE_ROUNDS=20 상수 추가, 초과 시 미해결 종료
C6 index.ts 임시 Director 해고를 try/finally로 감싸 에러 시에도 반드시 정리
C7 llm.ts 세마포어 구현 — MAX_CONCURRENT_AGENTS=10, 초과 시 큐에서 대기
C8 llm.ts 세션 TTL 30분 + 에이전트 완료 시 clearAgentSession() 즉시 정리

[2026-04-03] B섹션 안정성 개선 (B1~B5) — 완료

목적

코드 레벨 HIGH 버그 5건 일괄 처리. 실측에서 재현되지 않았으나 프로덕션 안정성에 필수.

#	문제	파일
B1	프로세스 좀비화 — SIGTERM 후 SIGKILL 폴백 없음	debate.ts
B2	DB 커넥션 미해제 — SIGINT 시 cleanup 없음	index.ts
B3	병렬 에이전트 에러 무시 — rejected 건 로깅/알림 없음	llm.ts
B4	워크플로우 원자성 없음 — 단계 실패 시 상태 미기록	index.ts
B5	Supabase RLS 미검증 — 서버 시작 시 권한 체크 없음	index.ts

구현 내용

B1 debate.ts killSectionAgents: proc.kill() → SIGTERM + 3초 후 SIGKILL (좀비 방지)
B2 index.ts SIGINT/SIGTERM 핸들러: Consigliere 종료 + debate.ts activeProcesses SIGTERM 정리. activeProcesses export 추가
B3 llm.ts callAgentsParallel: 실패 에이전트 목록 → FCM notifyAlert 전송
B4 index.ts 워크플로우 최상위 catch: 에러 메시지 DB 기록 + 회장 FCM 알림
B5 index.ts 서버 시작 시 SELECT+INSERT+DELETE 테스트 쿼리 → RLS 권한 확인

[2026-04-03] 실측 32 완료 — G15 완전 해결 확인 (6,337원)

결과

iOS 115 Swift 파일, 파싱 에러 0건 ✅
Android compileDebugKotlin 에러 0건 ✅
API tsc --noEmit 에러 0건 ✅
G15 ✅: lastSeenId=11507 확정 후 즉시 구독, id=11508 수신, 경쟁조건 없음
미해결 이슈 0건

[2026-04-03] G15 안 B 구현 (Realtime 경쟁조건 근본 해결)

변경 내용

server/src/orchestrator/supabase.ts — subscribeToMessages() async 전환
lastSeenId 확정 후 구독 시작 (3초 timeout + 폴링 fallback)
SUBSCRIBED gap catch-up: 구독 확정 시점에 누락 메시지 1회 조회/처리
초기화 실패 시 폴링 모드로 자동 강등 (서버 시작 실패 없음)
server/src/index.ts — await subscribeToMessages() 적용

해결 구조

기존: 구독 시작 → SUBSCRIBED → lastSeenId 비동기 init (경쟁조건 ❌)
변경: lastSeenId DB 조회 완료 → 구독 시작 → SUBSCRIBED gap catch-up (경쟁조건 ✅ 제거)

[2026-04-03] G21 최종 확인 + 실측 31 완료 (9,143원)

실측 31 결과

비용: 9,143원 | 에이전트: 6/6 ✅ | minVersion: 14.0 ✅
iOS: 82 Swift 파일, 파싱 에러 0건 ✅
Android: compileDebugKotlin 성공 ✅
BuildValidator:API: tsc --noEmit 3파일, 타입 에러 0건 ✅ (G21 완전 해결)

G21 수정 내용

buildValidateAPI() — readdirSync 1단계 깊이 탐색 추가
scaffold가 api/App/tsconfig.json에 생성하면 BuildValidator가 자동으로 발견
server/src/setup.ts — spawnSync(detached) → spawn().unref() 타입 오류 수정
server/src/orchestrator/llm.ts — execFile(detached) → spawn().unref() 타입 오류 수정

미해결 이슈

G15 (Realtime 미수신): 안 B 구조적 수정 대기

[2026-04-03] Capomastro 플랫폼 5개 추가 (G21 해결 + 로드맵 완성)

추가 플랫폼 (기본값 + --framework 오버라이드)

react — Vite + React + TS (기본값) / --framework nextjs → Next.js
web — Next.js + Tailwind (기본값) / --framework react → Vite
api — Express + TS (기본값) / --framework hono|fastify 향후 확장
server — WebSocket + Supabase Realtime (기본값)
db — Supabase migrations + RLS + seed (기본값) / --framework prisma 향후 확장

변경 파일

Capomastro/internal/generator/react/generator.go (신규)
Capomastro/internal/generator/web/generator.go (신규)
Capomastro/internal/generator/api/generator.go (신규)
Capomastro/internal/generator/server/generator.go (신규)
Capomastro/internal/generator/db/generator.go (신규)
Capomastro/main.go — 5개 platform case 추가
bin/Capomastro — 바이너리 교체
project-validator.ts — scaffoldProject() 추가
index.ts — 에이전트 역할별 scaffold 사전 호출

해결

G20: Android → scaffoldAndroidProject() 서버 호출
G21: api_dev → scaffoldProject('api') 사전 호출 → tsconfig.json 보장

[2026-04-03] Capomastro --platform api/react 추가 (G21 해결 + 로드맵)

변경

Capomastro: --platform api 추가 (Node.js/Express/TypeScript 뼈대)
tsconfig.json, package.json, src/index.ts, .env.example, .gitignore
Capomastro: --platform react 추가 (Vite + React + TypeScript 뼈대)
package.json, tsconfig.json, vite.config.ts, index.html, src/main.tsx, src/App.tsx
main.go: api/react case 추가
서버 index.ts: api/react 에이전트 포함 시 사전 뼈대 생성 호출
project-validator.ts: scaffoldAPIProject(), scaffoldReactProject() 추가

해결

G21: api_dev_1이 tsconfig.json 미생성 → BuildValidator 스킵 → 구조적 해결

[2026-04-03] G20/G21 원인 확정 및 수정 계획

원인

G20: Capomastro --platform android는 이미 완전 구현(gradle-wrapper.jar 자동 복사 포함). 서버가 단 한 번도 호출하지 않은 것이 원인.
G21: Capomastro에 --platform api 자체가 없음. Go 소스에 추가 필요.

수정 계획

G20: index.ts에서 에이전트 실행 전 Capomastro --platform android 호출 추가
G21: Capomastro Go 소스에 --platform api 추가 (tsconfig.json + package.json 생성) → 빌드 → 서버에서 호출

[2026-04-03] 실측 29 완료: G19 ✅ G20/G21 신규 발견

결과 (7,375원)

6/6 에이전트 완료 ✅
G19 ✅ 해결 확인: minVersion=14.0 — 회장 파싱값 우선 적용 정상 작동
iOS BuildValidator ✅ 92개 Swift 파일, 파싱 에러 0건
G20 신규: Android gradle-wrapper.jar 미생성 → BuildValidator 스킵
G21 신규: API tsconfig.json 미생성 → BuildValidator 스킵
G15: 경고 미발생 ✅
서버 로그: .consigliere/tests/실측029.log.gz

[2026-04-03] G19 수정: syncXcodeProjects 회장 요청 버전 우선 적용

변경

project-validator.ts:457 — syncXcodeProjects(projectDir, iosMinVersion?) 파라미터 추가
project-validator.ts:501~508 — 회장 전달값 우선, 없으면 pbxproj, 없으면 14.0 fallback
index.ts:377~384 — 회장 메시지에서 iOS 최소 버전 파싱 (iosMinVersion 변수)
index.ts:682, 739 — syncXcodeProjects 두 호출부에 iosMinVersion 전달

원인 (확정)

에이전트가 pbxproj에 IPHONEOS_DEPLOYMENT_TARGET = 16.0 작성 → syncXcodeProjects()가 그 값을 읽어 Capomastro에 그대로 전달 → pbxproj 16.0으로 재생성. Capomastro는 무고.

검증

실측 29 필요

[2026-04-03] 실측 28 완료: G19 신규 발견 (minVersion 재현)

결과 (6,652원)

6/6 에이전트 완료 ✅ (ios_dev_1, android_dev_1, api_dev_1, designer_1, db_dev_1, biz_dev_1)
BuildValidator:iOS ✅ 103개 Swift 파일, 파싱 에러 0건
BuildValidator:Android ✅ compileDebugKotlin, 에러 0건
BuildValidator:API ✅ 30개 TS 파일, tsc --noEmit 성공
G15: 경고 미발생 (안 C 진단 로그 정상 작동)
G19 신규: minVersion=16.0 재현 — 실측 27 해결(14.0) 후 재발. 구조적 강제 필요
서버 로그: /tmp/bigboss_os_test28.log

[2026-04-02] 실측 27 완료: G18/G17 검증 성공

결과 (5,683원)

G18 ✅: 6명 투입 확인 (designer_1, db_dev_1, biz_dev_1, api_dev_1, ios_dev_1, android_dev_1)
G17 ✅: minVersion=14.0 — 16.0 덮어쓰기 재현 없음. 자동 해결 확인
BuildValidator:iOS ✅ 82개 Swift 파일, 파싱 에러 0건
BuildValidator:Android ✅ compileDebugKotlin, 컴파일 에러 0건 (첫 성공)
BuildValidator:API ✅ tsc --noEmit 성공 (첫 성공)
서버 로그: /tmp/bigboss_os_test27.log

[2026-04-02] G18 해결: Multi-Director 복잡도 기반 에이전트 선택

문제

Phase 2 Director 프롬프트 "토큰 비용 절감, 최소 인원만" 지시 → 넷플릭스 클론(복잡) 앱에서도 6명 → db_dev_1만 선택

수정 (커밋 c39e6cd)

Director 프롬프트: 복잡도 기준 명시 (복잡=5명+, 보통=3~4명, 간단=1~2명)
복잡 앱 키워드: 스트리밍/결제/인증/마켓플레이스/iOS+Android 동시 → 에이전트 축소 최소화
합의 프롬프트: "다수 불필요 → 제외" 규칙을 복잡도 조건부로 변경

[2026-04-02] 실측 26b 완료: G16 검증 + G17 재현 + G18 신규 발견

결과

gradle=0, xcodebuild=0 ✅ (G16 적용 확인)
[Agent:db_dev_1] status=completed ✅ (onAgentComplete() H1~H6 토대 작동 확인)
BuildValidator:iOS 54개 Swift 파일 파싱 체크 성공 ✅
Capomastro pbxproj 동기화 완료 ✅
총 비용 1,869원
G16 검증 완료

신규 발견

G17 재현: minVersion=16.0 — db_dev_1 작업 후 Capomastro가 16.0으로 기록. 회장 지정 14 → 미반영
G18 신규: Phase 2 Multi-Director 편향 — "최소 인원" 프롬프트 지시가 너무 강함. 실측 26b에서 6명 → db_dev_1만 선택됨. 복잡도 기반 분류 기준 필요

[2026-04-02] G16 근본 해결: BUILD_SUCCESS 제거 + 검증 파이프라인

결정 배경

BUILD_SUCCESS = 텍스트 파싱 기반 품질 판단 → 취약, 모델 의존
H1~H6(회장 개입 기능) 토대: 에이전트 상태를 서버가 정확히 알아야 함
F4(haiku→sonnet 폴백 서버 검증 전환) 완성
G14 패턴(android_dev) 전체 역할로 확장

구현 항목 (순서)

validateProjectStructure: 역할별 최소 파일 수 체크 추가 (파일 0개 = 에러)
AGENT_SPEC 전체: BUILD_SUCCESS 제거, ios/api/web_dev 빌드 실행 금지
buildValidateAPI() 추가: tsconfig.json 탐색 → tsc --noEmit
codingRoles 재시도 블록 제거
onAgentComplete() 함수 추출: H1~H6 토대, 완료 이벤트 처리 단일 지점

구현 완료 (커밋 0244cad)

llm.ts: AGENT_SPEC 전체 BUILD_SUCCESS 제거, ios/android/api/web_dev 빌드 금지
project-validator.ts: iOS/Android 최소 파일 수 체크, buildValidateAPI() 추가
index.ts: codingRoles 재시도 블록 제거, onAgentComplete() 위치 확보, API 검증 흐름 추가

미해결

web_dev buildValidate: npm run build 환경 의존 → 나중
db_dev SQL 검증: 별도 설계 필요
H6 실제 DB 상태 기록: TODO 위치 확보됨, H6 구현 시 추가

[2026-04-02] 실측 25 완료: G14 buildValidateAndroid() 검증

결과

android_dev_1 gradle 실행 없음 ✅
BUILD_SUCCESS 정상 출력 (파일 작성 완료 신호) ✅
buildValidateAndroid() 실행됨 ✅
compileDebugKotlin 에러 0건 ✅
총 비용 4,158원 (실측 24 8,970원 대비 54% 절감 — 루프 제거 효과)
G14 완전 해결 확인

[2026-04-02] fix: 광고 UI 미흡 4건 수정 ✅

adI18n() 헬퍼 추가 → AdInfoSheet 내부 텍스트 ko/en 분기
if #available(iOS 16, *) 분기 → iOS 14/15 크래시 방어
브랜드명 폰트 6pt → 8pt
광고 배지 탭 영역 32×32 → 44×44 (Apple HIG 최소 탭 타겟)

[2026-04-02] fix: 광고 배지 법적 준수 완료 (글로벌 다국어 + 크기 + EU DSA 시트)

구현

adBadgeLabel(): 로케일 기반 다국어 함수 (ko→광고, ja→広告, zh→广告, fr→Pub, de→Anz., ar→إعلان, 기타→Ad)
배지 폰트 6pt → 9pt (Google AdMob 15px 기준 충족)
AdInfoSheet: 광고 배지 탭 시 광고주명·타겟팅 기준·법적 근거 표시 (EU DSA Art.26)
presentationDetents([.medium]): 하프시트로 표시

[2026-04-02] fix: 광고 배지 법적 준수 (글로벌 다국어 + 크기 수정)

이유

글로벌 앱 → 한국(표시광고법), 미국(FTC), EU(DSA), Apple/Google 정책 동시 준수 필요
한국: "AD" 단독 표기 → 표시광고법 위반 가능 (과징금 매출액 2%, 2년 이하 징역)
Google AdMob: 광고 배지 최소 15px 이상 (현재 6pt → 미달)
EU DSA: 광고 탭 시 광고주 정보 표시 의무

수정 내용

광고 배지 로케일 기반 다국어: ko→"광고", ja→"広告", zh→"广告", 기타→"Ad"
배지 폰트 6pt → 9pt (Google 15px 기준 충족)
광고 탭(onAdTap) 시 광고주 정보 시트 표시 (EU DSA 대응)

[2026-04-02] design: 사무실 오브젝트 광고 슬롯 구현 (OfficeObject 광고 확장)

구현 내용

OfficeObject에 adBrand: String?, onAdTap: (() -> Void)? 파라미터 추가
광고 있을 때: 황금색 테두리 글로우 + 우상단 "AD" 배지 + 브랜드명 표시
광고 없을 때: 기존 스타일 유지 (하위 호환)
신규 오브젝트 추가: 에어컨(❄️), 노트북(💻), 모션데스크(🪑)
광고 전용 오브젝트(에어컨/노트북/모션데스크): 탭해도 하단 패널 변화 없음

기본 광고 슬롯 배치 (더미)

오브젝트	더미 브랜드
냉장고	LG전자
자판기	코카콜라
에어컨	Samsung
커피머신	Nespresso
노트북	Apple
회의실	FastCampus
모션데스크	FlexiSpot

[2026-04-02] design: 사무실 오브젝트 광고 슬롯 설계 (OfficeObject 광고 확장)

이유

사무실 맵 내 모든 UI 오브젝트가 광고 인벤토리로 활용 가능
자판기·커피머신·책상·노트북·냉장고·에어컨·사무실디자인 → 브랜드 광고 슬롯
UI 단계부터 광고 슬롯 영역을 설계에 포함해야 나중에 레이아웃 깨지지 않음

광고 인벤토리 목록

오브젝트	광고 예시
자판기	음료 브랜드, 커피 브랜드
커피머신	커피 브랜드, 머신 제조사
책상	모션데스크 브랜드
노트북	삼성/애플/LG
냉장고	LG/삼성 냉장고
에어컨	삼성/LG 에어컨
사무실 디자인	FastCampus 등 공유오피스

설계 방향

OfficeObject에 adBrand: String? 파라미터 추가
광고 있을 때: 브랜드명 배지 + 미세한 글로우 테두리
광고 없을 때: 기본 스타일 유지
탭 시 광고 인터랙션 콜백 분리 (onAdTap)

[2026-04-02] feat: 사무실 맵 구현 (iOS OfficeMapView)

이유

현재 게임뷰: 검은 바탕 + 격자 + 에이전트 이모지뿐
실제 사무실 공간감 → 에이전트 시각화 몰입도 향상
기존 러프 구현(문서함, 휴지통, 에이전트 클릭) 위에 맵 레이아웃 추가

구현 내용 (UI 전용, 기능 로직 제외)

OfficeDimensions: 맵 크기(600×480), 벽 두께, 회의실/서버실 영역 상수
OfficeTiles: 체커보드 바닥 타일 (Canvas)
OfficeWalls: 외벽 4면 + 회의실/서버실 내벽 + 룸 레이블
DeskWithChair: 책상(갈색)+의자(회색) 16개 배치
비품 탭: 냉장고🧊 / 자판기🎰 / 커피☕ / 서버실🖥️ / 회의실📊 / 문서함📂 / 휴지통🗑️
OfficeSelection 케이스 확장 (fridge/vending/coffee/serverRoom/meetingRoom)
벽 충돌 처리: 회장이 벽 안쪽으로만 이동 (조이스틱 onChange clamp)

[2026-04-02] G14 구조적 해결: android_dev Generate-Only + 서버 Gradle 검증

결정 배경 (토론 결과)

토론 기준: 12가지 평가 기준 전체 적용 + 완전한 역할분리 원칙
핵심 판단: android_dev가 gradle 실행 = Generate-Verify 분리 위반 (#4)
루프 비용: 실측당 +15~30분, 자동화 실패 (#12)
환경 확인: Mac Mini에 Gradle 9.4.1 + Java 21 설치됨. PB가 gradlew 생성 확인됨.

설계 결정

android_dev AGENT_SPEC: gradle/gradlew 실행 금지. 코드 작성만. BUILD_SUCCESS = 파일 작성 완료.
buildValidateAndroid(): project-validator.ts에 추가. gradle wrapper(30초) → compileDebugKotlin(5분) 단계별 타임아웃.
index.ts: iOS 빌드 검증 흐름 옆에 Android 빌드 검증 병렬 추가.
G16(BUILD_SUCCESS over-retry): 이번 범위 외. G14 실측 후 별도 분석.

iOS/Android 대칭 구조

	iOS	Android
에이전트	코드 작성만	코드 작성만
빌드 검증	swiftc -parse	./gradlew compileDebugKotlin
검증 주체	project-validator.ts	project-validator.ts

구현 완료

llm.ts android_dev AGENT_SPEC: gradle 실행 금지, BUILD_SUCCESS 재정의
project-validator.ts buildValidateAndroid() 추가: gradle wrapper(30초) → compileDebugKotlin(5분)
index.ts Android 빌드 검증 흐름 추가 (iOS 패턴 대칭)
미해결: G16(BUILD_SUCCESS over-retry) — G14 실측 후 별도 분석

[2026-04-02] G14 근본 수정: android_dev 빌드 시도 1회 제한

근본 원인

"최대 3회" 지시를 에이전트가 무시하고 gradlew 수동 설치 → java -classpath 등 무한 시도
Android 빌드 환경(gradle 버전, wrapper jar)은 호스트 머신 의존 → 에이전트가 제어 불가

결정

빌드 시도 1회로 제한 + 실패 즉시 BUILD_SUCCESS 선언
Android 코드 정합성은 서버 구조 검증(validateAndroid)으로 충분
빌드 성공 여부보다 코드 완성이 우선

수정

llm.ts android AGENT_SPEC: 빌드 1회 시도, 실패/환경 없음 무관하게 즉시 BUILD_SUCCESS

[2026-04-02] android_dev_1 Gradle 루프 수정

근본 원인

AGENT_SPEC: ./gradlew compileDebugKotlin 강제
gradlew/wrapper jar 없으면 java -classpath gradle-wrapper.jar 무한 루프

수정

llm.ts generateAgentSpec: ./gradlew || gradle fallback 추가
gradle 환경 자체가 없으면 코드 완성 후 BUILD_SUCCESS 선언하도록 명시

[2026-04-02] 제품 방향 확정: BigBoss OS = 모델 배포 플랫폼

결정

모델 제작: 회장 본인이 직접
BigBoss OS 역할: 완성 모델을 유저에게 제공하는 플랫폼
배포 도메인: beethovain.com
유저: Mac Mini M4 Pro 48GB + 모바일 환경

의미

BigBoss OS는 단순 AI 툴이 아닌 모델 배포 + 서비스 플랫폼으로 포지셔닝
유저가 모델을 다운받거나, beethovain.com에서 바로 사용하는 구조

[2026-04-02] 전략 수정: 풀스택 커버리지 확장 (서버/웹/DB 추가)

변경

목표 모델 정체성: "모바일 특화" → "풀스택 개발 특화"
증류 데이터: 10만건 → 18만건 (서버/DB/웹/보안/인프라 추가)
비용: ~$360 → ~$730 (1회 투자)
LoRA 어댑터: 4종 → 9종
포지션: 풀스택 코딩 기준 Sonnet 4.6 수준

[2026-04-02] 전략 확정: 파인튜닝된 모델 블랜딩 → Opus 4.6 증류 → LoRA → RLHF

결정

쌩짜 베이스 블랜딩 → 파인튜닝/RLHF 완료 모델 블랜딩으로 방향 전환
이유: 학습된 능력 합산 → 증류 흡수율 향상 → 최종 성능 82~87% (기존 75~80% 대비 향상)
블랜딩 조합: Codestral 22B (코드 FT) + Mistral-22B-Instruct-v0.3 (SFT+RLHF) 6:4
Teacher: Opus 4.6 (CoT 증류 10만 건, ~$360)
LoRA: Swift / Kotlin / TS 어댑터 별도
RLHF: BigBoss OS 빌드 성공/실패 피드백 → DPO

[2026-04-02] docs: 쌀먹 유저 최대 퍼포먼스 전략 설계 (멀티기법 조합)

이유

타겟 유저: Mac Mini M4 Pro 48GB + 모바일, 외부 API 비용 0원
단일 기법으론 한계 존재 → 블랜딩+증류+파인튜닝+하이브리드 전부 조합
teacher=Opus 4.6, 최종 목표=Opus 4.6 코딩 특화 영역 근접

[2026-04-02] docs: 타겟 유저 프로파일 확정 + 로드맵별 모델 전략 기록

결정 내용

타겟 유저: Mac Mini M4 Pro 48GB 호스트 + iOS/Android 모바일 클라이언트
단기 목표 모델 성능: Haiku 4.5 수준
장기 목표 모델 성능: Opus 4.6 수준
근거: 커뮤니티 조사 결과 Mac Mini M4 Pro 48GB가 로컬 LLM 실사용 주력 하드웨어로 확인됨

[2026-04-02] docs: Claude Haiku vs 대체 경량 모델 비교표 추가

이유

alternative-models.md에 Haiku 기준 경량 모델 비교 섹션 없음
Worker / Edge Agent 역할에서 모델 선택 기준이 불명확
Haiku 성능 포지셔닝을 명확히 해서 역할 배정 의사결정에 활용

[2026-04-02] BuildValidator: swiftc -typecheck → -parse (false positive 수정)

근본 원인

swiftc -typecheck는 모듈 해석 필요 (UIKit, SwiftUI 등 iOS SDK)
CommandLineTools에는 iOS SDK 없음 → no such module 'UIKit' false positive
실제 코드 문제 없는데 에러 1건으로 계속 보고됨

수정

-typecheck → -parse 교체
-parse: 순수 문법/구조 체크만 (모듈 import 없이도 동작)
실제 타입 에러는 에이전트 자체 빌드(swiftc -typecheck with SDK)에서 잡음

[2026-04-02] missing_info + DELEGATE 동시 감지 시 에이전트 실행 중단 버그 수정

근본 원인

Router 응답에 DELEGATE 6개 + missing_info가 함께 있을 때
DELEGATE 파싱 성공 이후에도 missing_info 체크 실행 → return으로 에이전트 실행 중단
결과: 에이전트 한 명도 실행 안 됨

수정

index.ts: missing_info 체크 조건을 delegates.length === 0일 때만으로 제한
DELEGATE가 이미 있으면 missing_info 무시

[2026-04-02] Capomastro 에러 수정: xcodeproj_duplicate false positive

근본 원인

에이전트가 작업 중 ios/StreamApp.backup/ 같은 임시/백업 디렉토리 생성
findFiles()가 backup 디렉토리를 재귀 탐색 → xcodeproj 2개 감지 → 구조 에러 1건
구조 에러 1건 → G9 swiftc 스킵 (조건: structureErrors.length === 0)

수정

findFiles(): SKIP_DIRS 상수 추가 + backup, _bak 패턴 디렉토리 스킵
SKIP_DIRS: build, node_modules, .gradle, .build, DerivedData, __pycache__, Pods

[2026-04-02] G9 재설계: xcodebuild → swiftc -typecheck

문제

G9 실측에서 xcodebuild가 xcode-select 오류로 실행 안 됨
xcode-select: tool 'xcodebuild' requires Xcode, but active developer directory is CommandLineTools
CommandLineTools만으론 xcodebuild 불가 (Xcode.app 필요)

해결

xcodebuild 대신 swiftc -typecheck 사용
CommandLineTools만 있어도 Swift 타입 체크 가능 (컴파일은 안 해도 타입/문법 오류 잡음)
Android는 AGENT_SPEC에서 gradle compileDebugKotlin 명시 강화

[2026-04-02] G9: 서버 빌드 검증 — xcodebuild 에러 파싱 + 에이전트 재시도

목적

haiku가 생성한 코드에 빌드 에러 발생 (CoreData 타입 누락, Swift 6 미대응, iOS API 버전 불일치)
컴파일러가 완벽한 검증기: xcodebuild 에러를 파싱해 에이전트에게 피드백하면 자가 수정 가능
기존 구조 검증(validateProjectStructure)은 파일/경로 검증이라 컴파일 에러는 못 잡음

설계

project-validator.ts에 buildValidateIOS(projectDir) 추가
xcodebuild build -quiet 실행 (Mac + iOS 프로젝트 있을 때만)
에러 파싱: 파일:줄:열: error: 메시지 형식
ValidationIssue[] 반환 (type: 'build_error')
timeout: 120초 (빌드 길어지면 스킵)
index.ts: syncXcodeProjects() 후 buildValidateIOS() 호출
에러 있으면 해당 파일 담당 에이전트 특정 후 재시도
에이전트 특정 불가 시 QA 에이전트로 fallback

구현 완료

project-validator.ts: buildValidateIOS() + buildErrorsToIssues() 추가
process.platform !== 'darwin' or xcodebuild 없으면 즉시 return []
xcodebuild 에러 정규식 파싱, 중복 제거, 최대 20건 에이전트 전달
index.ts: 구조 검증 에러 0건일 때만 빌드 검증 실행 (중복 수정 방지)
iOS 에이전트 우선 → QA fallback
수정 후 pbxproj 재동기화
기존 구조 에러(QA)와 빌드 에러(iOS dev) 처리 분리

남은 과제

G10: haiku vs sonnet 판단 (실측 필요)

[2026-04-02] G8 재분류: xcode-select → Capomastro 책임

결정

G8 (xcode-select 경로 변경)을 setup.ts 과제에서 제외
setup.ts는 스택 무관 공통 인프라만 담당 (Ollama, Supabase 키, Claude API 키)
스택별 도구 체크(xcode-select, flutter doctor 등)는 Capomastro 책임
근거: Director가 스택 결정 → Capomastro가 스택에 맞는 환경 검증하는 것이 아키텍처 원칙에 부합

영향

G8은 Capomastro 개선 과제로 재배정
setup.ts 범위 확정: Ollama + Supabase + Claude API Key만

[2026-04-02] 실측 19 결과 + 남은 과제

실측 19 결과

pbxproj: 51/51 Swift refs 등록 ✅ (findFiles 버그 수정 효과)
sync 정상 실행 ✅ (48 Swift, CoreData=true, minVersion=14.0)
iOS 최소 버전: 14.0 ✅ (sync 덮어쓰기 방지 작동)
Android minSdk: 23 ✅
디렉토리 구조: ios/, android/, api/, docs/ 분리 ✅
pbxproj fullRel 경로 중복 → 파일명만 사용으로 재수정 (커밋 3661b07)
Team ID: keychain 자동 감지 → .env 자동 저장 구현

빌드 에러 (haiku 한계)

Cannot find type 'CachedWatchHistory' — CoreData 엔티티 타입 누락
Static property 'shared' is not concurrency-safe — Swift 6 미대응
'tint' is only available in iOS 16.0 or newer — iOS 14 타겟에 iOS 16 API 사용

남은 과제

G8: xcode-select 경로 변경 (회장 sudo 실행 필요)
G9: 서버 빌드 검증 — xcodebuild 에러 파싱 → 에이전트 재시도 (컴파일러 = 완벽한 검증기)
G10: haiku vs sonnet 판단 — G9 적용 후 실측으로 결정

[2026-04-02] pbxproj sync 버그 수정 (findFiles + syncXcodeProjects)

근본 원인

findFiles(dir, '.xcodeproj')가 .xcodeproj를 못 찾음
원인: .xcodeproj는 디렉토리인데, findFiles가 디렉토리면 재귀 탐색으로 분기 → endsWith 체크에 안 걸림
결과: syncXcodeProjects()가 xcodeproj를 못 찾아서 아예 실행 안 됨

수정

project-validator.ts findFiles(): 확장자 매칭을 디렉토리 분기보다 먼저 체크 (.xcodeproj 디렉토리 감지 가능)
project-validator.ts syncXcodeProjects(): 기존 pbxproj에서 IPHONEOS_DEPLOYMENT_TARGET 읽어서 --min-version 전달 (sync 시 16.0 덮어쓰기 방지)
실측 18b: sync 정상 실행, 39 Swift refs 등록, 최소 버전 보존 확인 필요

[2026-04-01] 프로젝트 디렉토리 구조 정리 + AGENT_SPEC 디렉토리 규칙

목적

archi/ 루트에 node_modules, package.json 등이 산발적으로 생성 → 정리 불가
서버 로그, Consigliere 인덱스가 프로젝트 루트에 혼재

규칙

archi/
  ios/         ← iOS 프로젝트
  android/     ← Android 프로젝트
  api/         ← API/백엔드 서버
  docs/        ← 워크플로우 + 에이전트 로그 + 서버 로그 + 기타 MD
    logs/      ← 에이전트 로그
    server/    ← 서버 로그
    design/    ← 디자이너 산출물

[2026-04-01] G1~G7 수정: pbxproj 경로 + 최소 버전

목적

실측 15에서 발견: pbxproj 경로 전체 불일치 (빨간 파일), 최소 버전 16 (회장은 14 지정)
Capomastro 경로 계산 버그 + AGENT_SPEC 최소 버전 미포함

[2026-04-01] AGENT_SPEC 통합 + 실측 14/15

실측 결과

실측 14 (SPEC 분리): iOS 31 Swift, Android 0 Kotlin (낭비 1,326원), API 692 TS (과잉). 총 7,594원
실측 15 (AGENT_SPEC 통합): iOS 43 Swift, Android 68 Kotlin ✅, API 0 TS ✅. 총 8,812원
Android 0파일 문제 해결. API 과잉 문제 해결. 서버 Verify(BUILD_SUCCESS) 양쪽 실측에서 작동 확인

변경

generateSharedSpec() + generateBuildVerify() + generateScopeSpec() → generateAgentSpec() 1개로 통합
역할별 필수 산출물 명시 (.swift, .kt, .sql 등), designer HTML 목업 3파일 제한

[2026-04-01] A2 해결: 빌드 검증 — 에이전트 자체 빌드 + 서버 Verify

목적

에이전트 코드 생성 후 빌드 검증 없음 → FootHeart v2에서 60+건 수동 수정
완전 자동화: 회장 수동 개입 0

구현 완료

server/src/orchestrator/llm.ts — generateBuildVerify(): 코딩 에이전트 역할 감지 → 플랫폼별 빌드 명령 자동 생성 (iOS xcodebuild, Android gradlew, Web/API tsc)
server/src/index.ts — BUILD_VERIFY를 SHARED_SPEC과 함께 에이전트 태스크에 자동 주입
server/src/index.ts — 서버 Verify: 에이전트 완료 후 BUILD_SUCCESS 확인 → 없으면 재시도 (최대 1회)
이중 구조: 에이전트 자체 빌드+수정 (컨텍스트 유지) + 서버 Verify 백업 (구조적 강제)

[2026-04-01] A1 해결: 에이전트 간 통신 — 사전 명세 주입 + 사후 grep 검증

목적

에이전트 병렬 실행 시 서로의 기술 선택을 모름 → 타입 중복, DB 불일치 발생 (FootHeart v2: 6건)
프롬프트 의존 없이, LLM 추가 호출 없이, 서버 코드로 구조적 해결

판단 기준

11개 기준 (실측 데이터, 회장 피드백, 단순성, Generate-Verify, 모델 가정 재검증, Anthropic 하네스 철학, 비용, 복잡→단순 진화, 하네스 정당성, 구현 복잡성, revfactory 패턴) 기반 평가
기존 최종 2안(Director 재요청)은 LLM 의존 + 비용 발생으로 탈락
신규 1안+2안이 실측 외 10/11 기준 충족

구현 완료

server/src/orchestrator/llm.ts — generateSharedSpec(): DELEGATE 태스크에서 아키텍처/DB/기술 키워드 감지 → SHARED_SPEC 자동 생성
server/src/index.ts — 에이전트 태스크 메시지 앞에 SHARED_SPEC 강제 주입 (프롬프트 의존 0)
server/src/index.ts — detectDuplicateTypes(): 에이전트 완료 후 Swift struct/class/enum + Kotlin data class/class/enum 중복 grep 스캔
기존 detectTechConflicts() (에이전트 stdout 기반) + 신규 detectDuplicateTypes() (파일 기반) 이중 검증

[2026-04-01] Router 오픈소스 전환: claude haiku → Ollama gemma3:4b

목적

Router의 역할은 회장 메시지를 읽고 DELEGATE 태그를 출력하는 단순 분류 작업
haiku API 호출(15원/요청) → 로컬 gemma3:4b(0원/요청)으로 전환
Ollama는 이미 설치됨, gemma3:4b도 설치됨 (3.3GB)
Consigliere 시맨틱 검색용 nomic-embed-text도 같은 Ollama 인스턴스에서 사용

구현

server/src/orchestrator/llm.ts — routeDirective() Ollama HTTP API로 교체
Ollama 실패 시 haiku 자동 폴백 (routeDirectiveWithClaude())
환경변수: OLLAMA_URL (기본 localhost:11434), ROUTER_MODEL (기본 gemma3:4b)
Router 프롬프트에 EXACT FORMAT 예시 추가 (gemma3:4b가 예시 없으면 형식 틀림)
모델: gemma3:4b (Q4_K_M 양자화, 3.3GB). gemma3:1b는 복잡한 요청에서 형식 깨짐 → 탈락
실측 6회: 배달앱, 채팅, 헬스장SaaS, 중고차, 소셜로그인, 반려동물앱 — 6/6 전부 성공
속도: 6~13초 (haiku 3~5초 대비 약간 느림), 비용 0원 (haiku 15원 → 0원)
형식 정확도: 100% (DELEGATE 태그, 에이전트 배정, 한국어 태스크 설명 모두 정상)
Ollama 필수 의존성: Router(gemma3:4b) + Consigliere(nomic-embed-text) 모두 Ollama 사용
ensureOllama() — 서버 시작 시 Ollama 체크 → 없으면 자동 spawn → 실패 시 process.exit(1)
haiku 폴백 제거 — Ollama 없으면 서버 시작 불가 (명확한 의존성)
설치 필수: brew install ollama && ollama pull gemma3:4b && ollama pull nomic-embed-text
npm run setup — setup.ts에서 Ollama 설치 확인 + 모델 자동 pull 포함

[2026-04-01] FCM 보완: ALERT 푸시 전파 + 뱃지 리셋 + 디바운스

목적

서버에서 ALERT 삽입 지점 10곳 중 1곳만 notifyAlert() 연결 → 전부 연결
iOS 뱃지가 1로 고정되는 문제 → 포그라운드 복귀 시 0으로 리셋
짧은 시간 내 중복 푸시 폭탄 방지 → fcm.ts에 30초 디바운스

구현 완료

#4 ALERT 푸시 전파: index.ts 8곳에 notifyAlert() 추가 (alert_response, Director 종합, missing_info, iOS/Android 쌍체크, 추가에이전트, 재요청 경로)
#6 뱃지 리셋: BigBossOSApp.swift의 AppDelegate에 applicationDidBecomeActive → badge 0
#8 디바운스: fcm.ts에 30초 title 기반 중복 방지 (isDuplicate()) + 자동 정리
#5 알림 탭 딥링크: iOS — didReceive → NotificationCenter → MainTabView selectedTab=0. Android — singleTop launchMode로 기존 Activity 재사용, ChatScreen이 기본 화면
#7 Android 알림 아이콘: ic_notification.xml 벡터 드로어블 (벨 아이콘) + AndroidManifest default_notification_icon / default_notification_channel_id 메타데이터
#9 알림 그루핑: fcm.ts — getCollapseTag() 유형별 태그 (task_complete/alert/debate/general). Android: collapseKey + notification.tag. iOS: apns-collapse-id. 같은 유형 알림은 교체됨
#10 토큰 만료 정리: fcm.ts — cleanupExpiredTokens() 30일 초과 토큰 자동 삭제. initFCM 시 1회 + setInterval 24시간 주기
#11 push_tokens RLS 강화: 039_push_tokens_rls.sql — 기존 전체 허용 정책 삭제. service_role: 전체, anon: INSERT/UPDATE만 (SELECT/DELETE 차단)

[2026-04-01] FCM 푸시 알림 iOS/Android 앱 연동

목적

서버 fcm.ts는 완성 상태이나 모바일 앱에 FCM 토큰 등록 + 푸시 수신 코드가 없음
iOS: FirebaseApp.configure(), AppDelegate, MessagingDelegate, 토큰→Supabase 등록
Android: firebase-messaging 의존성, FCMService, 토큰→Supabase 등록, 알림 채널
두 플랫폼 모두 push_tokens 테이블에 UPSERT로 토큰 저장

변경 파일

ios/BigBossOS/BigBossOS/BigBossOSApp.swift — Firebase 초기화 + AppDelegate + 푸시 권한
ios/BigBossOS/BigBossOS/SupabaseClient.swift — registerPushToken 추가
android/gradle/libs.versions.toml — firebase-bom, firebase-messaging, google-services 추가
android/build.gradle.kts — google-services 플러그인
android/app/build.gradle.kts — firebase 의존성
android/app/src/main/AndroidManifest.xml — POST_NOTIFICATIONS 권한 + FCMService
android/app/src/main/java/com/jupond/bigbossos/FCMService.kt — 신규
android/app/src/main/java/com/jupond/bigbossos/MainActivity.kt — 토큰 등록 + 알림 채널
android/app/src/main/java/com/jupond/bigbossos/SupabaseClient.kt — registerPushToken 추가

참고

iOS: Push Notifications capability + APNs 키(.p8) Firebase Console 등록 완료
Android: google-services.json 존재, 별도 설정 불필요
RLS 마이그레이션 039_push_tokens_rls.sql Supabase 적용 필요

[2026-04-01] FootHeart v2 iOS 수동 수정 + Capomastro 개선 + AI Status Bar

대화 흐름 및 의사결정

FootHeart v2 빌드 에러 수정 시작

회장이 Xcode 에러를 하나씩 보내주며 수정 요청
Swift 6 concurrency 경고 (PersistenceController, CoreDataManager, KeychainManager, CryptoService, HealthKitManager, HealthKitSyncService) → @unchecked Sendable + nonisolated(unsafe) + NSMergePolicy(merge:) 패턴 적용
깨진 #Preview 블록 12개 → 전체 주석처리

회장 지시: "전체적으로 다 수정해"

개별 에러 수정이 반복되자 회장이 "프로젝트 전체 코드파일 훑어서 버전관련에러 모두 수정" 지시
iOS 14 호환성 전수 스캔 실행 (30+ 파일, 60+ 수정)
주요 패턴: Section(""), LabeledContent, .background(_,in:), Canvas, .refreshable, .swipeActions, HKQuantityType(.xxx), Color.cyan, .formatted(), .alert(isPresented:)

반복 에러에 대한 회장 피드백: "같은 에러 계속 반복중"

HybridStepTracker의 Sending 'self' risks data races 에러가 3회 반복
처음: 로컬 변수 추출 → 실패
두번째: @preconcurrency import + @unchecked Sendable → 실패
세번째: [weak self] → 실패
의사결정: 근본 해결 — 클래스 전체를 @MainActor로 변경, delegate를 nonisolated으로 분리, DispatchQueue.main.async → Task { @MainActor in } 전환

CoreData 모델 누락으로 런타임 크래시

NSEntityDescription for entity name 'UserProfile' 에러
원인: xcdatamodeld 파일이 2개 (루트에 빈 파일 + CoreData/에 실제 파일). Xcode가 빈 파일 로드
수정: 빈 파일 삭제 + 누락된 6개 엔티티(HealthProfile, WorkoutSession, RoutePoint, MealRecord, WaterIntake, DailySummary) 추가

Info.plist 권한 누락으로 런타임 크래시

HealthKit 쓰기 권한(NSHealthUpdateUsageDescription) 없어서 크래시
수정: Debug/Release 모두에 HealthKit 읽기/쓰기 + Location 권한 키 추가

NaN 크래시

차트/바에서 0 나누기 → CALayer position contains NaN 크래시
수정: maxValue 0 방어, barWidth.isFinite 체크

회장 지시: "xcode 문제점 싹다 리스트업해"

전체 수정 내역을 카테고리별 정리 (9개 카테고리, 60+ 건)

회장 지시: "projectbuilder에 적용할게 있어?"

8건 이슈 도출 (#14~#21)
ISSUES.md에 등록 + 상세 내역 문서화

회장 의사결정: "코드 버전은 에이전트단에서 처리해야"

#18(min-version별 API)은 Capomastro가 아니라 에이전트 HARD_RULES에서 해결
최종 분류:
Capomastro 직접 수정: #14(--team), #16(중복 xcdatamodeld)
에이전트 HARD_RULES: #17(@main), #18(API 버전), #21(Swift 6)
서버 후처리: #15(Info.plist), #19(App Groups), #20(HealthKit)

회장 재분류: "#15,19,20도 에이전트단"

서버 syncXcodeProjects 확장이 아니라 에이전트가 직접 파일 생성하도록 HARD_RULES로 해결
최종: Capomastro 2건만 우리가 수정, 나머지 6건은 에이전트 HARD_RULES

Capomastro #14, #16 구현 완료

#14: --team 플래그 추가, App/Tests/UITests 6개 buildConfiguration 전부에 DEVELOPMENT_TEAM 삽입
#16: .xcdatamodeld 하위 디렉토리 존재 시 생성 스킵
Go 빌드 성공, 바이너리 배포

B차트 진행: AI Status Bar

회장: "에이전트에게 시켰다가 서버 엉켰다"는 배경 설명
확인 결과: Status Bar 코드 자체가 없음 (시작 전에 중단)
회장: "니가 해 에이전트 맡기지말고"
AIStatusBar.swift 신규 생성: ViewModel + View, activity 로그 파싱, 에이전트별 상태 표시

회장 아이콘 수정 지시

생성: 🤖 → 📝, 저장: ✍️ → 🗄️

AI Status Bar 구현 진행 중

AIStatusBar.swift 생성 완료 (ViewModel + View)
MainTabView.swift 연결 완료 (TabView 상단에 StatusBar 배치)
pbxproj 수정 불필요 (PBXFileSystemSynchronizedRootGroup — Xcode 16.3 자동 파일 동기화)
구현 완료: 에이전트 상태 실시간 표시, 단계 아이콘(📨🧠📝🗄️✅💤), 접기/펼치기, 진행률
파서 수정: 서버 실제 activity 로그 형식에 맞춰 파싱 로직 변경 (🤖 {id} 작업 시작 / ✅ {id} 작업 완료 등)

FCM 푸시 알림 iOS/Android 연동 ✅

서버 fcm.ts, firebase-service-account.json, GoogleService-Info.plist, push_tokens DB 모두 기존 완료
iOS: AppDelegate + FirebaseApp.configure + MessagingDelegate + 토큰→Supabase UPSERT 완료
Android: firebase-messaging + FCMService + 알림 채널 + 토큰→Supabase UPSERT 완료

코드 변경 요약

FootHeart v2 iOS (~/Desktop/archi/footheart-v2/)

Swift 6 concurrency: 8파일 10건
iOS 14 API 호환: 30+파일 30+건
깨진 #Preview: 12파일
.fontWeight: 15+곳
CoreData 모델: 6엔티티 추가 + 빈 xcdatamodeld 삭제
pbxproj: Signing 4타겟, Info.plist 3키
런타임 NaN: 3건
기타 컴파일 에러: 10+건

Capomastro (~/Desktop/Projects/OpenSource/Capomastro/)

main.go: --team 플래그 추가
ios/generator.go: Config.Team 필드 + xcdatamodeld 중복 방지
ios/pbxproj.go: 모든 타겟 buildConfiguration에 DEVELOPMENT_TEAM 삽입

BigBoss OS iOS 앱 (~/Desktop/Projects/OpenSource/bigbossos/ios/)

AIStatusBar.swift: 신규 생성 (ViewModel + View)
MainTabView.swift: 미수정 (다음 단계에서 StatusBar 연결 예정)

문서

docs/ISSUES.md: #14~#21 등록 + 상세 내역
docs/token-optimization.md: 테스트 11/13 추가, FootHeart v2 후속 수정 교훈
docs/DASHBOARD.md: 04-01 활동, 미해결 이슈 8건
docs/CHANGELOG.md: 이 항목
archi/실측테스트10/test-report.md: 후속 수정 내역 추가

[2026-03-31] Capomastro pbxproj 자동 동기화

문제

에이전트가 Swift 파일 생성 → Xcode pbxproj에 미등록 → Xcode에서 파일 안 보임
매번 수동 "Add Files" 필요

수정

Capomastro 소스 수정: appSourceFiles()를 디렉토리 스캔 방식으로 변경
writeGroups()에 PBXGroup 트리 구조 추가 (폴더 계층 유지)
+특수문자 포함 파일명 따옴표 처리
서버: callAgentsParallel() 완료 후 syncXcodeProjects() 자동 실행

[2026-03-31] 유저 동적 모델/effort/thinking 설정

3가지 경로

회장 메시지 자연어: "오푸스로 해줘 effort high 확장사고" → Director가 [AGENT_CONFIG] 태그 출력 → 서버 파싱
UI 설정: 모바일/웹에서 모델 선택 → DB agents 테이블 반영
DB 직접: agents.model, agents.effort, agents.thinking_budget 컬럼

우선순위

DB 설정 < 회장 메시지 자연어 (메시지가 있으면 메시지 우선)

[2026-03-31] FCM 푸시 알림 구현

목적

에이전트 작업 완료/ALERT 발생 시 회장 모바일에 푸시 알림
회장이 대시보드를 계속 보고 있지 않아도 알림으로 확인 가능

구현

server/src/orchestrator/fcm.ts — Firebase Admin SDK로 발송
트리거: ALERT 전송 시, 에이전트 전체 완료 시, 토론 5회 이상 시
Firebase 서비스 계정 키: server/firebase-service-account.json (.gitignore)

[2026-03-31] 프로젝트 구조 검증 — 하이브리드 (코드 검증 + 조건부 QA 에이전트)

결정 (토론 합의 + 회장 하이브리드 채택)

Phase 1: validateProjectStructure() 코드 검증 (0원, 수 밀리초)
xcodeproj 중첩, 패키지 경로 불일치, 빈 파일, namespace 불일치
Phase 2: 문제 발견 시에만 QA 에이전트 spawn → 수정 방안 제시 + 자동 수정
문제 0건이면 QA 스킵 (비용 0)
문제 있을 때만 에이전트 투입

[2026-03-31] #1 역할별 모델 믹스 구현

결정 (회장)

설계/판단 에이전트 → sonnet (아키텍처, 설계, 보안 감사 = 판단력 필요)
코딩 에이전트 → haiku 시도, 빌드 실패 시 sonnet 자동 폴백
유저가 에이전트별 모델을 직접 오버라이드 가능

[2026-03-31] Issue #12: 에이전트 Xcode 프로젝트 파일 경로 문제

문제

biz_dev가 FootHeart/Business/에 파일 생성 → Xcode .xcodeproj 멤버 밖 → Xcode 미인식
ios_dev가 FootHeartApp.swift, ContentView.swift를 빈 파일로 남기고 App/ 하위에 실제 코드 생성 → Xcode가 빈 파일만 인식
원인: 병렬 에이전트가 서로 다른 디렉토리 구조로 파일 생성

수정 방향

Business/ 파일들을 FootHeart/FootHeart/ 하위로 이동 (Xcode 프로젝트 멤버 안)
루트 FootHeartApp.swift, ContentView.swift 빈 파일 삭제 (App/ 하위에 실제 코드 존재)
HARD_RULES에 "iOS 프로젝트 파일은 반드시 {프로젝트명}/{프로젝트명}/ 하위에 생성" 규칙 추가

[2026-03-31] 에이전트 stdout MD 저장 → Consigliere 인덱싱 (완전한 문서화)

결정

에이전트 출력을 축소하지 않음 (회장 취지: 모든 걸 빠짐없이 기록)
에이전트 stdout 전부 docs/logs/{agentId}-{timestamp}.md로 자동 저장
Consigliere가 docs/**/*.md로 자동 인덱싱 → 에이전트 판단 근거 영구 검색 가능
실측테스트9에서 검증 완료 (4개 로그 파일 생성 확인)

[2026-03-31] 미해결 6건 일괄 수정

수정 항목

워처 broadcast 미수신 — Supabase Realtime broadcast 통신 검증+수정
Consigliere 검색 주입 미확인 — 로깅 강화 + 실측 검증
입력 토큰 ~0 — stream-json 한계 확인, total_cost_usd 기반으로 전환
Multi-Director 비용 과다 — 간단 앱 감지 시 토론 스킵 로직
[DEBATE] 미발동 — 워처 수정 후 자연 발생 대기
debates/ MD 미생성 — debate 발동 시 자동 생성 로직

[2026-03-31] Consigliere 통합 — 자가 학습 피드백 루프 (8단계)

설계 철학 (회장)

"에이전트가 일할수록 Consigliere가 똑똑해지고, Consigliere가 똑똑해질수록 에이전트가 덜 싸우는 피드백 루프"

8단계 구현 계획

살아있는 메모리 — 에이전트 A 기록 → 즉시 인덱싱 → 에이전트 B가 검색 발견 → 충돌 방지
16역할 전용 가중치 — Consigliere RoleWeights에 BigBoss OS 역할별 문서 우선순위 확장
플러그인 도메인 특화 — .consigliere.toml에 debate/checklist 파일 타입 + 회장결정/ALERT/DELEGATE 태그 룰
토론 전 증거 수집 — 회장 과거 결정 + 과거 토론 + 관련 규칙 + 모순 감지 → 증거 기반 토론
세션 연속성 자동화 — 시작 시 snapshot diff, 종료 시 snapshot 저장 (MEMORY.md 수동 관리 대체)
에이전트 자기 컨텍스트 — 작업 전 자기 과거 결정 검색
API 서버 상시 — consigliere serve 서버와 동시 시작, Node.js SDK 호출 (spawn 오버헤드 0)
회장 대시보드 — consigliere ui로 문서 검색/모순 확인/토론 이력 조회

구현 방식

호출: consigliere serve 상시 + Node.js SDK
검색: hybrid 기본, Ollama 없으면 BM25 폴백
주입: --append-system-prompt (HARD_RULES 뒤)
인덱싱: 서버 시작 + 에이전트 docs/ 변경 후 + 토론 MD 저장 후 + 세션 종료
스냅샷: 세션 종료 저장 + 시작 시 diff
실패: silent fallback

[2026-03-31] ProjectMemory → Consigliere 전환

결정

ProjectMemory가 Consigliere로 이름 변경 (회장 자체 개발, Go 1.18+, MIT 라이센스)
GitHub: github.com/Lee-JuYeon/Consigliere
BigBoss OS에 도입 완료 (.consigliere.toml + .consigliere/index.db)

Consigliere 핵심 기능

할루시네이션 제로 (원본 텍스트만 반환)
3가지 검색: BM25 키워드 / 시맨틱(벡터) / 하이브리드
역할별 검색 우선순위 (developer, director, security)
모순 감지 (문서 간 충돌 자동 스캔)
버전 스냅샷 + diff + 시점 복원
~13MB 단일 바이너리, 완전 오프라인, $0
Git Hook 자동 재인덱싱
JSON API + Node.js SDK

BigBoss OS 설정

인덱싱: docs/**/*.md, CLAUDE.md, agents/**/.md, checklists/.md, marketplace/*.md
검색: top_k=5, min_score=0.3

[2026-03-31] Router ALERT 제거 + alert_response Director 직행

문제

Router(haiku, -p)가 ALERT 보냄 → 회장 응답 → Router 다시 받음 → 컨텍스트 없음 → 또 ALERT → 무한 루프
원인: stateless(-p) 프로세스에 stateful(ALERT→응답) 동작 부여

수정 (4인 전문가 토론 합의)

Router에서 [ALERT] 완전 제거. DELEGATE만 출력.
정보 부족 시 missing_info 포함 DELEGATE 출력. Director가 회장에게 질문.
alert_response는 Router 우회 → Director(-c) 세션 직행.
Director 질문 대기 상태 플래그 관리.

[2026-03-31] Router haiku 전환 + 워처 프로세스 분리

Router haiku 전환

Router는 [DELEGATE] 태그만 출력 → haiku로 충분
sonnet 대비 더 빠르고 저렴 (haiku: $0.8/$4 vs sonnet: $3/$15)

워처 프로세스 분리

문제: 서버 1개가 에이전트 완료를 기다리는 동안 [DEBATE] 감지해도 즉시 중단 불가
해결: 서버(메인) + 워처(트리거) 2개 프로세스로 분리
서버: 회장 메시지 수신, spawn 관리, 결과 종합
워처: 에이전트 stdout 실시간 감시, [DEBATE] 감지, 즉시 proc.kill(), 토론 실행

[2026-03-31] Director 종합 보고 입력 축소 — 요약만 전달

문제

에이전트 전원 출력 원문을 그대로 Director에게 전달 → 입력 토큰 폭발
실측: 에이전트 7명 출력 합산 ~150K 토큰 → Director 입력으로 전부 주입

수정

에이전트 출력을 앞 500자로 요약하여 전달
원문은 DB에 저장되어 있으므로 필요 시 Director가 Read로 조회 가능

[2026-03-31] HARD_RULES 축소 — 역할별 분리로 토큰 절감

문제

HARD_RULES 93줄(~2,000 토큰)이 모든 에이전트에게 동일하게 주입
ALERT/DELEGATE 예시, Capomastro 경로 등은 Director에게만 필요
에이전트 N명 × 불필요 토큰 = 낭비

수정

HARD_RULES → HARD_RULES_COMMON(공통) + HARD_RULES_DIRECTOR(Director 전용) 분리
에이전트는 COMMON만 받음 (축소)
Director는 COMMON + DIRECTOR 받음 (기존과 동일)

[2026-03-31] Multi-Director 토론 기반 에이전트 투입 판단

문제

Director 1명이 혼자 에이전트 투입을 결정 → 매번 7~8명 최대 투입 → 토큰 낭비
간단한 물마시기앱에 보안 2명 + 디자이너 = 39% 비용 낭비

결정

Director를 복수로 고용 가능 (N명)
회장 지시 → Director N명이 먼저 토론 → 복잡도 판단 + 에이전트 선정 + 기술 선택
합의 후 DELEGATE → 필요한 에이전트만 투입
회장이 명시하면("간단하게", "보안 철저히") Director 판단보다 회장 지시 우선

[2026-03-31] 토큰 사용량 세부 로깅 추가

목적

총 소모 토큰 수 실시간 추적
Router/Director/Agent별 토큰 소모 내역 세분화
비용 추정 (USD + KRW) 자동 계산
회장이 어디서 왜 토큰이 많이 쓰이는지 파악 가능

수정

llm.ts: stream-json의 usage 이벤트 파싱 → 토큰 카운터 누적
전역 토큰 카운터 (세션 단위)
각 호출 완료 시 개별 토큰 + 누적 토큰 + 비용 로그 출력

[2026-03-31] 토론 시스템 Phase 1 구현

설계 원칙

프롬프트 의존 최소화. 서버 코드로 구조적 강제.
노드 트리는 서버가 관리 (에이전트가 기억할 필요 없음)
토론 큐, 섹션 관리, 프로세스 kill/restart 전부 서버 레벨

구현 모듈

sections.ts — 섹션 정의, 에이전트↔섹션 매핑, 관련 섹션 탐색
node-tree.ts — 문제 추적 노드 트리 (OPEN/BLOCKED/RESOLVED/INVALIDATED)
debate-queue.ts — 토론 큐 (FIFO + 우선순위 선점)
debate.ts — 토론 오케스트레이터 (감지→정지→토론→테스트→재개 전체 루프)
DB 마이그레이션 — debates, debate_nodes 테이블

[2026-03-31] 기술 일관성 4-Layer 방어 체계 구현

문제

병렬 에이전트 간 기술 선택 불일치 (Issue #9: db_dev→CoreData vs ios_dev→UserDefaults)
프롬프트만으로는 90% 수준, 구조적 보완 필요

4-Layer 설계 (전문가 토론 2차)

Layer 1: HARD_RULES 기본 기술 스택 컨벤션 (fallback)
Layer 4A: Director 종합 보고 시 기술 일관성 검토 지시
Layer 3: Post-execution 경량 충돌 감지 (키워드 grep)
Layer 2: [TECH_STACK] 태그 파싱→에이전트 system prompt 주입 (데이터 확인 후)

수정

Phase 0: Layer 1 + Layer 4A (프롬프트 수정)
Phase 1: Layer 3 (서버 코드 추가)

[2026-03-30] 에이전트 승인 불필요 규칙 + doc-template 정리

문제

doc-template/CLAUDE.md에 "계획 승인 전 코드 작성 금지" 규칙이 PROJECT_DIR로 복사됨
에이전트가 이 규칙을 읽고 회장 지시인데도 계획 승인을 기다리는 비결정적 동작 발생
4명 전문가 토론 결과: A안(충돌 규칙 제거) + B안(HARD_RULES override) 이중 방어 채택

수정

doc-template/CLAUDE.md: "세션 시작 시 필수 읽기", "핵심 규칙" 섹션 제거. Capomastro 기술 규칙만 유지
archi/CLAUDE.md: 동일하게 개발 프로세스 규칙 제거
HARD_RULES에 추가: "회장 지시 = 구현 승인 완료, 즉시 코드 작성"
비가역적 작업(배포·삭제·프로덕션 데이터 변경·결제 행위)은 ALERT 유지
rules.md 회장 결정 기록

[2026-03-30] 에이전트 캐릭터 페르소나 배정

결정

드라마/영화/실존 인물 기반으로 에이전트 성격 부여
17명 배정 완료, 나머지 역할은 미배정

배정 요약

Director: 김창섭 (메이플스토리)
Architecture: 길포일 (실리콘밸리), 일론 머스크
Backend: 모리츠 침머만, 레니 샌더 (인터넷으로 마약을 파는 법)
Frontend: 남도산 (스타트업), 가쿠 (트릴리온 게임), 마크 주커버그
Design: 한소희
Security: 스티브 잡스
QA: 코쿠류 키리카, 타카하시 린린 (트릴리온 게임)
Research: 텐노지 하루 (트릴리온 게임)
Marketing: 신세경
PM: 백승수 (스토브리그)
VC 자문: 한지평 (스타트업), 구승효 (라이프)

반영 파일

docs/plan.md — 캐릭터 페르소나 테이블 추가
docs/rules.md — 회장 결정 로그
docs/CHANGELOG.md — 본 항목

[2026-03-30] Issue #8 해결: Director DELEGATE 미발동

근본 원인 (3개)

parseDelegates() 정규식 오류 — AGENT_ID_PATTERN = /^[a-z][a-z0-9_]*_\d+$/이 _숫자 끝을 강제. 실제 에이전트 ID(backend_dev, pm, api_dev 등)는 숫자로 안 끝남 → DELEGATE 파싱 100% 실패
Dashboard ↔ llm.ts 역할 ID 불일치 — Dashboard: api_dev, qa, perf / llm.ts: api_developer, functional_tester, performance_tester → 도구 제한 미적용 (전원 무제한 접근)
Router/Director BIGBOSS_OS_AGENT=1 누락 — callAgent()에만 있고 routeDirective()/callClaude()에는 없음 → hook 간섭 가능

수정 내용

parseDelegates(): 정규식 기반 → validAgentIds: string[] 매개변수 기반 매칭으로 전환
index.ts: 메시지 처리 시작 시 고용 에이전트 ID 조회 → parseDelegates() 전 호출부(4곳)에 전달
roleAllowedTools/roleEffort: Dashboard 호환 ID 16개 에일리어스 추가 (pm, cto, backend_dev, api_dev, frontend_dev, designer, security_lead, security_researcher, qa, perf, devops, dba, tech_writer, data_analyst, backend_lead, frontend_lead)
Router/Director spawn: env: { ...process.env, BIGBOSS_OS_AGENT: '1' } 추가
supabase.ts: 기존 빌드 에러 수정 (payload.content 타입 에러)

영향

Router가 출력한 DELEGATE가 정상 파싱됨 → 에이전트 병렬 실행 복원
Dashboard에서 고용한 에이전트도 올바른 도구 제한 적용
hook 간섭 없이 Router/Director 실행

[2026-03-30] 문서 전체 점검 + 갱신

문제

DASHBOARD.md: 최종 갱신 2026-03-24, 6일간 미갱신
"미해결 이슈 0건" → 실제 Issue #8 CRITICAL 열려있음
"3명 에이전트" → 실제 24역할 Director 체계
"7개 마이그레이션" → 실제 36개
plan.md: 전체 미체크, 실제로 다수 완료됨. 에이전트 구조 16명→24역할 미반영
WBS.md: 최종 기록 2026-03-23, 7일간 미갱신

수정

DASHBOARD.md: 현재 상태, 진행 현황, 최근 활동 전면 갱신
plan.md: Phase 1/2/3 체크 상태 갱신, 에이전트 구조 24역할로 갱신, 플랫폼 상태 갱신
WBS.md: 전체 진행 현황 갱신, 일일 작업 기록 2026-03-24~30 추가

남은 작업 리스트 누락 발견

Issue #8 (Director DELEGATE 미발동) — CRITICAL
iOS OfficeView TODO 3건
Soldato 개발 (명세 완료)
Office Objects 구현 (명세 완료)

[2026-03-29] Office 탭: 문서함 + 휴지통 뷰 추가

수정

Office 맵에 📂 문서함, 🗑️ 휴지통 오브젝트 추가
탭 시 하단에 상세 뷰 표시
일단 네모 + 이모지로 간단 구현

[2026-03-29] 에이전트 작업 디렉토리 플랫폼별 분리

문제

iOS+Android가 같은 폴더에 공존 (WeatherApp/ 안에 xcodeproj + gradle)
플랫폼별 분리가 안 됨

수정

A: callAgent에서 role별 cwd 분리 (ios_developer → archi/ios/, android_developer → archi/android/)
B: HARD_RULES에 Capomastro --out 경로 규칙 (ios → {PROJECT_DIR}/ios/, android → {PROJECT_DIR}/android/)
서버가 플랫폼 디렉토리 자동 생성

수정 파일

server/src/orchestrator/llm.ts — callAgent cwd 분리 + HARD_RULES 경로 규칙

[2026-03-29] 조이스틱: 회장 중앙 고정 + 맵 이동 방식으로 변경

문제

회장 캐릭터가 화면에서 움직이는 방식 → 회장은 중앙 고정, 맵이 움직여야 함

수정

ceoPosition → mapOffset으로 변경
회장: 항상 화면 정중앙 고정
에이전트/격자: mapOffset만큼 반대 방향으로 이동
조이스틱 드래그 → mapOffset 변경

[2026-03-29] 바텀 네비게이션 + 사무실 탑뷰 맵

결정

바텀 네비 2탭: 💬 Chat (기존), 🏢 Office (새로)
Office 탭: 상단 1/3 탑뷰 사무실 맵 + 하단 2/3 에이전트 상세
캐릭터: 이모지 + 하단 라벨 (에이전트 이름)
화면 중앙: 회장 캐릭터 (👔)
가상 패드: 방향키 (상하좌우) 하단에 배치
고용된 에이전트만 맵에 표시

수정 파일

ios/BigBossOSApp.swift — TabView 추가
ios/OfficeView.swift — 신규: 탑뷰 맵 + 가상 패드
ios/ChatView.swift — 헤더에서 Agent 버튼 유지

[2026-03-29] 종합 보고 DELEGATE 재귀 실행 + Director 위임 강화

문제

Director 종합 보고에 [DELEGATE] 포함 시 서버가 무시 → android 미생성
Director가 iOS만 먼저 DELEGATE하고 Android는 종합 보고에서 추가 위임
"모바일 프로젝트" = iOS+Android 동시. 하나만 만드는 건 비정상

수정

B: summaryResult에도 DELEGATE 파싱 + 실행 (재귀 방지: 최대 깊이 2)
A: Director system_prompt에 "모바일 = iOS+Android 동시 위임" 규칙 추가

[2026-03-29] ContentView.swift — Hello Building Manager View 추가

목적: 'Hello Building Manager' 텍스트를 표시하는 SwiftUI ContentView 생성
파일: ios/BigBossOS/BigBossOS/ContentView.swift (신규)

[2026-03-29] test.swift Hello World SwiftUI View 작성

목적: 간단한 Hello World SwiftUI View 테스트 파일 생성
파일: test.swift (신규)

[2026-03-29] 프로젝트별 에이전트 관리

문제

agents 테이블이 전역 → 모든 프로젝트에서 같은 에이전트 공유
A프로젝트에 iOS개발자, B프로젝트에 BE개발자 — 분리 불가

결정

agents 테이블에 project_dir 컬럼 추가
서버: PROJECT_DIR 기준 해당 프로젝트 에이전트만 로드
모바일 고용/해고: 현재 연결된 서버의 프로젝트에만 적용
Director는 프로젝트별 1명 자동 생성

수정 파일

supabase/migrations/036_agents_project_dir.sql — project_dir 컬럼 추가
server/src/index.ts — 에이전트 조회 시 project_dir 필터
server/src/orchestrator/llm.ts — callClaude 에이전트 목록 조회 시 필터
ios/SupabaseClient.swift — 에이전트 API에 project_dir 파라미터

[2026-03-29] 서버 검증 레이어: Director 응답 구조적 보정

설계 원칙

프롬프트 = 의도 전달, 구조 = 강제 실행
Director 판단을 먼저 신뢰하되, 구조적 누락 시 시스템이 보정
"왜 잘못했냐" 추궁이 아니라 "이런 사태가 발생하지 않는 구조"

서버 검증 흐름

Director 응답 수신
  → DELEGATE 있음 → 정상 파싱 → 에이전트 병렬 실행
  → ALERT 있음 → 회장에게 질문 (정상)
  → 둘 다 없음 → 코딩 필요한 상황인데 위임 안 함
    → 서버가 Director에게 1회 재요청: "에이전트에게 위임해주세요"
    → 그래도 DELEGATE 없으면 → 회장에게 그대로 전달

구조적 방어 레이어

레이어	방식
도구 차단	--tools 물리적 제한
에이전트 목록	DB에서 동적 주입
응답 검증	서버가 DELEGATE/ALERT 유무 확인
재요청	1회 재시도 (프롬프트가 아닌 시스템 루프)
부분 실패	Promise.allSettled + 부분 완료 반환

수정 파일

server/src/index.ts — Director 응답 검증 + 재요청 로직

[2026-03-29] Issue #8: Director DELEGATE 미발동 수정

문제

Director가 [DELEGATE] 태그를 출력하지 않고 "도구가 없다" ALERT만 반복
CLI 테스트(--system-prompt 직접 전달)에서는 정상 DELEGATE 발동

근본 원인 (4가지)

callClaude()에 --system-prompt 누락: callAgent()는 DB system_prompt를 --system-prompt로 전달하지만, callClaude(Director)는 --system-prompt를 전혀 사용하지 않음. Director는 CLAUDE.md의 "PM" 정체성을 따름
HARD_RULES 모순 지시: "YOU must run Capomastro via Bash" → Director에게 Bash 없는데 직접 실행 지시 → "도구 없다" 루프 유발
고용 에이전트 목록 미주입: Director가 에이전트 ID를 모르니 DELEGATE 형식을 쓸 수 없음
DB system_prompt 너무 약함: "You NEVER write code directly"는 소극적. "도구 없다 ALERT" 패턴으로 해석됨

수정사항 (코드 변경 상세)

1. HARD_RULES → Director/Agent 분리 (llm.ts:93-151)

HARD_RULES → HARD_RULES_DIRECTOR + HARD_RULES_AGENT로 분리
Director용: "YOU must run Capomastro via Bash" → "개발 에이전트에게 DELEGATE하라"
Director용: DELEGATE 규칙 강화 (반드시 출력하라)
Agent용: 원래 HARD_RULES 유지 (Bash 직접 실행)

2. callClaude()에 --system-prompt 추가 + 에이전트 목록 주입 (llm.ts:221-260)

DB에서 고용된 에이전트 목록 조회 (agents 테이블, director 제외)
Director 전용 system prompt 런타임 생성:
"You are the Director. Your ONLY purpose is to ANALYZE and DELEGATE."
"NEVER complain about missing tools"
"HIRED AGENTS: ..." (동적 목록)
[DELEGATE] 형식 예시
--system-prompt directorSystemPrompt 인자 추가

3. callAgent()에서 HARD_RULES_AGENT 사용 (llm.ts:407)

--append-system-prompt HARD_RULES → --append-system-prompt HARD_RULES_AGENT

4. callClaude()에서 HARD_RULES_DIRECTOR 사용 (llm.ts:255)

--append-system-prompt HARD_RULES → --append-system-prompt HARD_RULES_DIRECTOR

수정 파일

server/src/orchestrator/llm.ts — HARD_RULES 분리, callClaude() system-prompt 추가, 에이전트 목록 주입, callAgent() HARD_RULES_AGENT 사용
docs/ISSUES.md — 이슈 #8 등록
docs/CHANGELOG.md — 본 항목

[2026-03-28] 병렬 spawn 서버 통합

문제

현재 callClaude()가 단일 에이전트만 spawn → PM 혼자 모든 작업 처리
DB에 고용된 에이전트들이 실제로 동작하지 않음
병렬 테스트 스크립트로 검증은 완료 (3개 동시 spawn 성공, 18.4s vs 순차 37.4s)

결정

PM → Director로 교체 (Musk 스타일, 운영 총괄)
CLI = 에이전트. 에이전트 수 = CLI 프로세스 수
-p 유지 (매 작업마다 spawn/종료, 메모리 걱정 불필요)
--session-id로 에이전트별 세션 격리 + 대화 연속성
에이전트별 --system-prompt (DB agents.system_prompt) 적용
병렬 실행: Promise.allSettled
[DELEGATE] 태그로 Director가 에이전트에게 위임
조직: Director(고정) → 9개 섹션 21개 프리셋
추후 프리셋 파이프라인 + Director 자동 설계로 확장 예정

조직 구조

회장 (모바일)
  └── Director (고정)
        ├── Architecture: System, Data, Cloud
        ├── Backend: API, Business Logic, Database
        ├── Frontend: Web, iOS, Android, Designer
        ├── Security: App, DB, Infra
        ├── QA: Functional, Performance
        ├── DevOps: CI/CD, Infrastructure
        ├── Research: Tech, Market
        ├── Marketing: Growth, Content
        └── Finance: Accountant

에이전트별 allowedTools (4명 병렬 토론 결과)

Director:       Read, Grep, Glob, WebSearch
Architect:      Read, Grep, Glob, Write(docs/), Edit(docs/)
Security:       Read, Grep, Glob, Bash(audit)
Developer:      전체 허용
Designer:       전체 허용
QA:             Read, Grep, Bash(test)
DevOps:         Read, Grep, Bash, Edit(infra/)
Researcher:     Read, Grep, WebSearch
Marketer:       Read, Grep, WebSearch
Accountant:     Read

도구 제한 + 프로세스 게이트 조합
Director는 코딩 도구 물리적 차단 → DELEGATE 강제
Architect/Security는 제한적 허용 (설계검증/감사용)
Developer는 전체 허용, 단 향후 리뷰 게이트 추가 예정

수정 파일

supabase/migrations/ — PM→Director 교체
server/src/orchestrator/llm.ts — callAgent에 allowedTools 적용, Director 도구 제한
server/src/index.ts — Director DELEGATE 감지 → 병렬 실행 → 결과 종합
ios/AgentRosterView.swift — 아코디언 리스트, 21개 프리셋, 섹션 접힘/펼침
docs/cli-harness.md — allowedTools 역할별 매핑 추가

[2026-03-29] 서버 시작 순서 + 모델 기본값 + DELEGATE 테스트

문제

Vercel URL + 페어링 코드가 Agent Roster 뒤에 표시 → 앞으로 이동
setup.js가 LLM_MODEL=sonnet 하드코딩 → opus로 변경
Director DELEGATE 미발동 → 테스트 후 원인 파악

수정 파일

server/src/index.ts — Vercel URL + 페어링 코드를 Roster 앞으로 이동
scripts/setup.js — LLM_MODEL=opus
server/src/orchestrator/llm.ts — DELEGATE 관련 테스트/수정

[2026-03-29] Director 도구 제한 + 모델 통일 + 파서 수정

문제

--dangerously-skip-permissions가 --allowedTools를 무시 → Director가 코딩 직접 수행
DELEGATE 형식이 agent_id: id\ntask: 방식으로 출력 → 기존 파서 미대응
에이전트 모델이 haiku/sonnet 혼용 → 전체 opus 4.6 통일
AgentRoster 섹션 열림/닫힘 버그

결정

Director: --tools "Read,Grep,Glob,WebSearch,WebFetch" + --permission-mode dontAsk (코딩 도구 물리적 제거)
전체 에이전트 모델: opus (claude-opus-4-6)
Developer 등 전체 허용 에이전트: --dangerously-skip-permissions 유지
parseDelegates: 새 형식 대응
5명 토론 → 4명 검증 토론으로 해결책 도출 및 실제 CLI 테스트 검증 완료

effort 레벨 (역할별)

Director/Architect/Security/QA/Researcher: high (사고 필요)
Developer/Designer/Marketer/Accountant/DevOps: medium (실행 위주)

수정 파일

server/src/orchestrator/llm.ts — Director spawn 방식 변경, 모델 opus, 파서 수정, effort 매핑
ios/AgentRosterView.swift — 섹션 토글 버그 수정

[2026-03-28] Alert Panel UI 재디자인

결정

ALERT 라벨: 테마색 배경 + 흰 텍스트, 상단 border 위에 걸치는 형태
border: 좌+우+상단(ALERT 라벨 좌우로 분리), 하단 없음 (MessageInput 연결)
선택지: 세로 라디오 버튼 (Yes / Yes but... / No / 직접 입력)
원형 체크: 테마색, 종 이모지 삭제, description 삭제

구현

ios/ChatView.swift AlertPanel 재작성
HARD_RULES에 [OPTIONS: a | b | c] 형식 규칙 추가
서버(llm.ts): [OPTIONS:] 파싱 → msg_type:'alert' + options 필드
iOS AlertPanel: 동적 옵션 렌더링 (Claude가 제공하는 옵션 그대로)

[2026-03-28] 에이전트 시스템 개편: PM Only + 고용/삭제 UI

문제

초기 시드에 16명 에이전트가 하드코딩 → 유저가 선택권 없이 전원 고용 상태
에이전트 역할 설명이 없어 어떤 에이전트를 고용해야 할지 판단 불가
고용/삭제 UI가 단순 추가/삭제만 가능, 프리셋 역할 선택 불가

결정

DECIDED: 초기 상태 PM 1명만 (회장의 직속 매니저)
DECIDED: 에이전트 프리셋 목록을 코드에 정의 (역할+설명 포함)
DECIDED: 모바일 UI — "현재 직원" + "고용 가능" 두 섹션 구조
DECIDED: PM은 삭제 불가 (필수 에이전트)

구현

supabase/migrations/032_seed_pm_only.sql — 기존 에이전트 삭제, PM만 유지
ios/AgentRosterView.swift — 전체 재작성: "현재 직원" + "고용 가능" 2섹션 구조
8개 프리셋 (경리, BE아키텍트, BE보안, BE개발, FE아키텍트, FE개발, 리서처, 마케터)
각 프리셋에 역할 설명 포함
고용 가능 섹션: 2열 그리드, ✅/⬜ 고용 상태 + ＋－ 카운터로 동일 직종 복수 고용 가능
셀 레이아웃: 좌상단 체크+이름, 우상단 ＋－, 중앙 아이콘, 하단 역할 설명
id 규칙: role_1, role_2, role_3... (suffix 자동 증가)
최대 인원 제한 없음
PM은 해고 불가 (필수 에이전트)

[2026-03-28] 세션 4: Capomastro 연동 + 실시간 로그 스트리밍

결정

DECIDED: 서버 regex 파싱 제거 → Claude CLI가 자연어 이해하고 Capomastro 직접 실행
DECIDED: --output-format stream-json으로 Claude 작업 과정 실시간 스트리밍
DECIDED: iOS ActivityLogView → bottom sheet 리스트로 로그 표시

구현

CHANGED: server/index.ts — 프로젝트 생성 regex/스캐폴딩 로직 188줄 제거
CHANGED: llm.ts HARD_RULES — Claude가 Capomastro 직접 실행하도록 변경
CHANGED: scripts/create-project.js — 자체 로직 → Capomastro 바이너리 위임
IMPLEMENTING: llm.ts — stream-json 파싱 + Supabase 로그 전송
IMPLEMENTING: iOS ActivityLogView — bottom sheet 로그 리스트

[2026-03-24] 세션 3: 3명 에이전트 구현 + 기술스택 확정

결정

DECIDED: Anthropic 답변 대기 없이 구현 진행
DECIDED: 에이전트 캐릭터 3명만 먼저 (PM, BE Dev, FE Dev), 나머지 나중에 추가
DECIDED: 기술스택 확정 — Web(TS/CSS/JS), Android(Kotlin+Jetpack Compose), iOS(Swift+SwiftUI)

구현

CHANGED: agents 폴더 정리 (옛 17명 구조 삭제 -> 3명 새 구조)
CHANGED: definitions.ts 3명 에이전트 정의
CHANGED: channels.ts 3개 채널 (all_hands, pm_ceo, dev)
CHANGED: types/index.ts AgentRole 16명 지원 (확장 대비)
CHANGED: workflow.ts 5단계 파이프라인 (PM분석->BE+FE병렬->셀프리뷰->PM크로스리뷰->PM보고)
CHANGED: QR 페어링 → TOTP 방식 (6자리 코드, 30초 유효, 업계표준 RFC 6238)
CHANGED: 프로젝트 구조 정리 (server/dashboard/ios/android 분리)
IMPLEMENTED: PM/BE/FE CLAUDE.md 캐릭터 작성 (기술스택 포함)
IMPLEMENTED: 서버 동적 세션 시작/종료 (addSession/stopSession/restartSession)
IMPLEMENTED: 웹 에이전트 관리 UI (추가/제거) + Agents 탭
IMPLEMENTED: Office 뷰 동적 레이아웃 (에이전트 수에 맞게 자동 배치)
IMPLEMENTED: iOS 앱 기본 구조 (Swift + SwiftUI, 2탭, AI Status Bar)
IMPLEMENTED: Android 앱 기본 구조 (Kotlin + Jetpack Compose, 2탭, AI Status Bar)
IMPLEMENTED: TOTP 페어링 (서버 6자리 코드 생성 + iOS/Android 입력 화면)
IMPLEMENTED: 푸시 알림 서비스 (APNs + FCM 구조, DB 토큰 관리)
IMPLEMENTED: paired_devices, push_tokens DB 마이그레이션

[2026-03-23] 세션 2: 속도 개선 + 16명 스타트업 + 모바일 앱 설계

서버/속도

CHANGED: spawnSync → spawn persistent session (30초→5초)
LEARNED: 터미널 세션은 풀 기능, spawn은 stdin/stdout 제한적
LEARNED: Channels는 이미 열린 세션에 push → ~5초 (spawn과 동일 원리)
DECIDED: 백그라운드 spawn 유지 (Channels 정식 후 전환 검토)

에이전트 구조

CHANGED: 17명 → 4명 → 8명 → 16명 에이전트 구조
DECIDED: 16명 스타트업 구조 (PM,CTO,BE×3,FE×3,보안×2,QA,Perf,DevOps,DBA,Writer,Analyst)
DECIDED: PM이 경리+리서치 겸임
DECIDED: 아키텍처를 개발자 기본소양으로
DECIDED: 에이전트 수는 유저가 자유롭게 결정. PM이 시스템 리소스 기반 최대 수 보고
DECIDED: 에이전트 이름/역할/CLAUDE.md/skills를 유저가 모바일에서 직접 설정
DECIDED: 기본 에이전트는 프리셋 제공. 편집/커스텀 생성 자유
DECIDED: 에이전트 생성/편집 시 PM이 초안 작성 → 회장 컨펌/수정요청/직접작성 선택
DECIDED: 변경 시 CLAUDE.md+skills 파일에 즉시 반영 + 세션 재시작

수익 모델

DECIDED: 유저 과금 $0 절대 원칙
DECIDED: 사무실 PPL — 2D 사무실 내 브랜드 자판기/소품 픽셀 이미지로 광고 수익
DECIDED: 자기계발 탭 제휴 — 시원스쿨, 인프런 등 교육 업체 협업으로 수익
DECIDED: 수익 발생 시 공모전 개최 — 총상금 1000만원, 모바일로만 제품 개발 대회

모바일 앱

DECIDED: iOS(Swift) + Android(Kotlin) 네이티브 앱 별도 개발
DECIDED: 바텀 네비 2탭 (🏢사무실 + 📚자기계발)
DECIDED: 상단 AI Status Bar — 모든 탭에서 에이전트 실시간 상태
DECIDED: 대기 시간(5~120초) 활용 → 자기계발 탭에서 영상/학습
DECIDED: QR 페어링으로 앱-호스트PC 연결 (1분 만료, 1회용)
DECIDED: 기기 fingerprint/UUID + device allowlist로 접근 제한

보안

LEARNED: spawn 방식은 gray area — 공식 문서는 claude -p와 Agent SDK 안내
DECIDED: Anthropic 공식 답변 대기 중 (Conversation ID: 215473584984215)
DECIDED: 답변 전까지 4~5개 세션으로 보수적 운영 권장

구현

IMPLEMENTED: 체크리스트 탭 추가
IMPLEMENTED: 처리 단계 표시 (receiving→thinking→calling→writing)
IMPLEMENTED: 회장 메시지 즉시 표시 (optimistic update)
IMPLEMENTED: 파이프라인 워크플로우 (병렬+순차 최적화)
IMPLEMENTED: docs 구조화 (doc-template 기반)

[2026-03-22] 세션 1: 프로젝트 생성

DECIDED: BigBoss OS 프로젝트 생성
DECIDED: Supabase + Vercel + Claude CLI 구조
DECIDED: Node Tree 커뮤니케이션 (branch→review→merge)
DECIDED: No Opinion Left Behind 정책
DECIDED: 무조건 프리티어
DECIDED: 회장은 웹/모바일에서만 소통
IMPLEMENTED: 17명 에이전트 + 18개 채널
IMPLEMENTED: 웹 대시보드 (칸반, 사무실, 회의록)
IMPLEMENTED: Supabase Auth (이메일)
IMPLEMENTED: RLS + 보안 헤더 + Rate Limiting
IMPLEMENTED: i18n (10개 언어)
IMPLEMENTED: 보안 체크리스트 (19항목)
FIXED: #1 쉘 특수문자 에러
FIXED: #2 메시지 중복
FIXED: #3 React 에러
FIXED: #4 시크릿 노출

변경 이력

[2026-05-14] BigBoss OS 공식 웹사이트 구축 완료 (site/)

[2026-05-14] Ralph 루프 감사 — 묶음 A: G175/G176 (debate 루프 정체 감지 + 비용 상한)

[2026-05-14] Ralph 루프 감사 — 묶음 B: G177 (생성 프로젝트 git 체크포인트)

[2026-05-14] Ralph 루프 감사 — 묶음 C: G178/G179 (크래시 복구 + 런타임 상태 영속화)

[2026-04-29] G174 Bugfix — C레벨 섹션별 분리 호출 (Gemma 컨텍스트 대응)

[2026-04-28] G173 Bugfix — processNextDebate() 배선 완료 (토론 실제 실행)

[2026-04-28] test-record 완료 시 sync-ssd 자동 호출

[2026-04-28] recipes → blueprints 네이밍 통일

[2026-04-28] Capomastro GitHub fetch — recipe 소스 분리

[2026-04-28] IDE Recipe MD 시스템 + Capomastro ViewHolder 재설계

[2026-04-26] IDEDriver Vision Loop — ScaffoldAgent GUI 자동화

IDEDriver Vision Loop — 구조 개선 (2026-04-26)

[2026-04-25] G170 Architecture Decision — Worker Output Contract 규격화 (Disk-diff as Source of Truth)

[2026-04-25] G168 Bugfix Protocol 완료 — Write tool 워커 과소출력 오감지 → consecutive_timeouts SCRAM 근본해결

[2026-04-25] G167 Bugfix Protocol 완료 — Worker 유니코드 경로 혼동 → phantom_success 근본해결

[2026-04-25] G166 Bugfix Protocol 완료 — G87 merger 무제한 흡수 → consecutive_timeouts SCRAM 근본해결

[2026-04-25] G161 Bugfix Protocol 완료 — CEO_MODEL env 잔재 절차 수정

[2026-04-25] G165 Bugfix Protocol 완료 — docs 워커 JSON 파싱 실패 근본해결

[2026-04-25] G164 Bugfix Protocol 완료 — scaffold platform 감지 3중 신호 OR

[2026-04-24] 실측119 완료 — G163 RESOLVED, G162 REGRESSED, G164/G165 신규

[2026-04-24] G162+G163 Bugfix Protocol 완료 — Worker scaffold pre-seeding + Read 재추가

[2026-04-24] 실측118 완료 — G158·G160 VERIFIED, 신규 G161~G163, Q20 12/20

[2026-04-24] G160 O3 pipelining nextPreflight UnhandledRejection 크래시 근본해결 (Bugfix Protocol)

[2026-04-24] G158 SR02 soldato Unknown adapter SCRAM 근본해결 (Bugfix Protocol)

[2026-04-24] G155~G157 Q03/Q10/Q16 lifecycle 마커 추가 + X06 status 필드 완비 (Bugfix Protocol)

[2026-04-24] G150~G154 Q07/Q09/Q11/Q13 lifecycle 마커 5종 추가 (Bugfix Protocol 전부 적용)

[2026-04-24] G145~G149 Q20 전부 PASS — 라이프사이클 마커+기능 완성 (G145/G146/G147/G148/G149)

[2026-04-21] Track C 장애주입 F10/F11/F12 어댑터 훅 배선 (WHAT)

[2026-04-21] G138 consecutive_timeouts Bugfix Protocol — 근본해결 완료 (WHAT)

[2026-04-21] G139 phantom_success Bugfix Protocol — 근본해결 완료 (WHAT)

[2026-04-21] Track B 도메인 독립성 실측 N=5 kickoff (WHY)

[2026-04-21] cycle 10 완주 — 실측102 G114 RESOLVED (WHAT)

실증

cycle 10 구현

회장 지시 "사이클 4번 더" 완수 (cycle 7~10)

[2026-04-21] cycle 10 착수 — G114 Ollama strict-JSON 모드 (WHY)

[2026-04-21] cycle 9 완주 — 실측101 G113 breakthrough (WHAT)

실증

cycle 9 구현

노출된 후속 이슈

[2026-04-21] cycle 9 착수 — G113 Worker file-content 전송 채널 (WHY)

[2026-04-21] cycle 7 완주 — 실측100 G112 resolved + G113 노출 (WHAT)

cycle 7 구현 (확장)

신규 G113 — stub 확장 미수행 노출

[2026-04-21] cycle 7 착수 — G112 빈 스코프 seed (WHY)

[2026-04-20] cycle 6 완주 — 실측098 semantic visibility milestone (WHAT)

cycle 6 Bugfix 구현 (docs/bugfix/097-cycle6-worker-no-op-prevention.md)

실측098 실행 증거

신규 이슈

측정 축 전환

자료

[2026-04-20] cycle 6 착수 — G110 no-op worker 차단 (WHY)

[2026-04-20] cycle 5 완주 — 실측097 첫 E2E 파이프라인 관통 (WHAT)

cycle 5 Bugfix 구현 (docs/bugfix/096-cycle5-enum-semantic-mapping.md)

부수 fix — DIAMOND_MODEL env 누락 근본 해결

실측097 결과

산출물

다음 차원 (cycle 6 후보)

[2026-04-20] cycle 5 착수 — G109 enum semantic drift (WHY)

[2026-04-20] 4-Cycle Gemma 벤치마크 완주 — 실측096 (FAIL@Worker) + cycle 4 Bugfix 확증

cycle 4 Bugfix (docs/bugfix/095-cycle4-missing-field-defaults.md)

실측096 결과 (cycle 4 Bugfix 검증)

산출물

결정된 엔지니어링 원칙 (4 cycle 누적)

남은 과제 (미해결)

[2026-04-20] cycle 4 검증 — 실측095 (FAIL@CTO) + cycle 2+3 Bugfix 효과 확증

확증된 cycle Bugfix

신규 발견 (G108)

[2026-04-20] cycle 3 완료 — 실측093 (FAIL) + IR coercion boundary 추가

신규 발견 (G107)

cycle 3 Bugfix (docs/bugfix/093-cycle3-ir-coercion.md)

산출물 (cycle 3)

[2026-04-20] cycle 3 개시 — 실측093

[2026-04-20] cycle 2 완료 — 실측092 결과 + no-spec-refusal Skill 추가

cycle 2 신규 발견

cycle 2 Bugfix 채택 (docs/bugfix/092-cycle2-no-spec-refusal.md)

산출물 (cycle 2)

[2026-04-20] Gemma 4-cycle 체인 — cycle 2 개시 (실측092)

[2026-04-20] Skill Engine (cycle 1 bugfix) + Gemma 4회 실측 사이클 개시

[2026-05-14] BigBoss OS 공식 웹사이트 구축 완료 (`site/`)

G83 — Scaffold iOS 멱등성 (`scaffolding-agent.ts:63~`)

G84 — parseCEOMessage 2차 메시지 기본값 폴백 (`parser.ts`, `index.ts:50,1026,1338`)

G85 — Simulator.app 3회 팝업 (`project-validator.ts:656~`)

G55 — Phase B gantt/raci timeout (`spec-issuer.ts:166`)

[2026-04-16] G81-R 근본 해결 — `--permission-mode dontAsk` → `bypassPermissions`

[2026-04-15] G58 근본 해결 — `callStatelessForDocs` 호출자별 타임아웃 파라미터화

[2026-04-15] G59 근본 해결 — `toRel()` 을 Node `relative()` 로 교체 + test-pipeline 실전 검증 추가

[2026-04-15] G54 근본 해결 (2차) — `syncXcodeProjects` 삭제 + `regenerateXcodeProject` 전면 교체