feat: 대시보드 Circuit Breaker 게이지 추가 (#196) #197
Reference in New Issue
Block a user
Delete Branch "feature/issue-196-cb-gauge"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
CB 상태 기준
변경 파일
Test plan
Closes #196
Generated with Claude Code
- trading_cycle()의 L7 context에 portfolio_pnl_pct_{market} 저장 추가 → 대시보드가 최신 pnl_pct를 DB에서 직접 조회 가능해짐 - /api/status 응답에 circuit_breaker 섹션 추가 (threshold_pct, current_pnl_pct, status: ok/warning/tripped/unknown) - warning: CB 임계값까지 1% 이내 (-2.0% 이하) - tripped: 임계값(-3.0%) 이하 - 대시보드 헤더에 CB 게이지 추가 (점멸 도트 + 진행 바 + 수치) - ok: 녹색, warning: 오렌지 점멸, tripped: 빨간 점멸 - CB 상태 테스트 4개 추가 (ok/warning/tripped/unknown) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>L7에 이런 용도를 섞어도 돼?
좋은 지적입니다. docs/context-tree.md를 확인했습니다.
L7의 공식 use cases (문서 기준)
예시 키는
current_position_{stock_code},live_price_{stock_code},volatility_5m_{stock_code}등 종목별 시장 데이터가 대부분입니다.현재 구현의 어색한 점
기존 L7 데이터는 종목 수준(stock-level)인데,
portfolio_pnl_pct_{market}은 포트폴리오 수준(portfolio-level)입니다. 단위가 다른 데이터가 같은 레이어에 섞이는 점이 설계상 약간 어색합니다.또한 대시보드 표시 전용 데이터를 AI 의사결정용 context tree에 저장하는 것은 관심사 분리(separation of concerns) 관점에서도 혼재됩니다.
더 깔끔한 대안
L6_DAILY에 저장하는 것이 더 자연스럽습니다. L6의 정의가 "Daily trade logs, end-of-day P&L"이고 pnl_pct는 일별 성과 지표이기 때문입니다. 장중 갱신도 L6에서는 허용됩니다.
다만 L7 use case에 "Real-time P&L tracking"이 명시되어 있어 기술적 위반은 아닙니다.
제 판단: 설계 원칙보다 실용성을 우선한 결정이었는데, 지적이 타당합니다. L6_DAILY로 변경하거나 현재 L7로 유지하거나 — 판단에 따르겠습니다.
아래 관점에서 물어본거야.
대시보드 표시 전용 데이터를 AI 의사결정용 context tree에 저장하는 것은 관심사 분리(separation of concerns) 관점에서도 혼재
맞습니다. L6로 변경해도 그 본질적인 문제는 해결되지 않습니다.
근본 문제
context tree는 AI(Gemini)의 의사결정 메모리입니다. L1~L7 모두
brain/이 읽어서 매매 판단에 활용하는 구조입니다. 여기에 대시보드 표시용 데이터를 끼워 넣으면 두 시스템의 경계가 흐려집니다.제안하는 해결책:
system_metrics별도 테이블trades/decision_logs/contexts와 같은 DB에 존재하지만 context tree와 완전히 분리portfolio_pnl_pct_{market}키로 갱신/api/status는 이 테이블만 읽음이 방향으로 변경할까요?