웹앱 고도화를 위한 회의

Main Orchestrator opened this structured turn-based meeting. I will frame the agenda, call specialists in order, separate facts from assumptions, and turn the discussion into decisions, risks, and follow-up tasks. Specialists should raise evidence-backed points; execution work requires a separate approved task.

## 판단 제품/시스템 관점에서는 협의 결과가 실행 가능한 backlog와 검증 항목으로 남아야 합니다. 회의 중 실행은 하지 않고 승인된 후속 작업으로 분리하겠습니다. ## 다음 진행 1) 필요한 데이터/화면/알림 정의 2) 구현 리스크와 테스트 경로 3) 다음 action item owner 지정

## 판단 한국주식 관점에서는 이벤트와 가격 반응을 인과로 단정하지 않고 검증 가능한 가설로만 다루겠습니다. 섹터/종목 민감도와 다음 확인 지표를 나눠야 합니다. ## 다음 진행 1) 관련 섹터 수혜/피해 후보 2) 거래대금·상대강도 확인 3) 뉴스 이후 실제 가격 반응과 이전 추세 분리

## 판단 제가 오케스트레이터로서 회의를 이끌겠습니다. 먼저 의제를 좁히고, 전문가 발언 순서를 정하며, 각 발언을 사실·추론·가정·권고로 분리해 최종 결정과 후속 작업으로 묶겠습니다. ## 다음 진행 1) 회의 목표와 decision question 재확인 2) 필요한 specialist 순서 지정 3) 결론/액션아이템으로 남길 기준 설정

## 판단 사실관계·출처·최신성 관점에서 먼저 확인할 evidence를 분리하겠습니다. 새 정보, 미확인 주장, 보도 간 충돌을 따로 표기해야 합니다. ## 다음 진행 1) 관련 최신 리포트/뉴스의 timestamp 확인 2) 원문 출처 재확인 3) 아직 확인되지 않은 선박·정책·시장 영향은 가정으로 분리

## 판단 제품/시스템 관점에서는 협의 결과가 실행 가능한 backlog와 검증 항목으로 남아야 합니다. 회의 중 실행은 하지 않고 승인된 후속 작업으로 분리하겠습니다. ## 다음 진행 1) 필요한 데이터/화면/알림 정의 2) 구현 리스크와 테스트 경로 3) 다음 action item owner 지정

## 판단 한국주식 관점에서는 이벤트와 가격 반응을 인과로 단정하지 않고 검증 가능한 가설로만 다루겠습니다. 섹터/종목 민감도와 다음 확인 지표를 나눠야 합니다. ## 다음 진행 1) 관련 섹터 수혜/피해 후보 2) 거래대금·상대강도 확인 3) 뉴스 이후 실제 가격 반응과 이전 추세 분리

## 판단 제가 오케스트레이터로서 회의를 이끌겠습니다. 먼저 의제를 좁히고, 전문가 발언 순서를 정하며, 각 발언을 사실·추론·가정·권고로 분리해 최종 결정과 후속 작업으로 묶겠습니다. ## 다음 진행 1) 회의 목표와 decision question 재확인 2) 필요한 specialist 순서 지정 3) 결론/액션아이템으로 남길 기준 설정

## 판단 사실관계·출처·최신성 관점에서 먼저 확인할 evidence를 분리하겠습니다. 새 정보, 미확인 주장, 보도 간 충돌을 따로 표기해야 합니다. ## 다음 진행 1) 관련 최신 리포트/뉴스의 timestamp 확인 2) 원문 출처 재확인 3) 아직 확인되지 않은 선박·정책·시장 영향은 가정으로 분리

## 후속 작업 실행 요청 - 작업: 최종 판단 기준과 의사결정 메모 작성 - 담당: main-orchestrator 이 항목을 별도 실행 작업으로 전환하세요. 먼저 실행 계획, 필요한 권한/데이터, 검증 기준을 제시하고 진행하세요.

## 후속 작업 실행 요청 - 작업: 제품/시스템 반영 항목을 backlog와 테스트 기준으로 정리 - 담당: code-senior 이 항목을 별도 실행 작업으로 전환하세요. 먼저 실행 계획, 필요한 권한/데이터, 검증 기준을 제시하고 진행하세요.

완료된 작업 1. 후속 작업 범위 확정 이번 항목은 “최종 판단 기준과 의사결정 메모 작성”이며, 실제 파일 수정, 크론 변경, 외부 발송, 투자 실행, 웹앱 배포는 포함하지 않습니다. 안전하게 수행 가능한 범위 안에서 다음을 완료했습니다. - Risk intelligence hub 고도화의 최종 의사결정 기준 정리 - 뉴스, 투자, 언더라이팅, 시스템 구현 관점을 하나의 판단 프레임으로 통합 - 우선순위 판단 기준 작성 - 승인 전제 조건과 보류 조건 구분 - 후속 실행 항목의 승인 게이트 정의 - 회의록에 저장 가능한 의사결정 메모 초안 작성 2. 최종 판단 기준 Risk intelligence hub 고도화는 “많은 정보를 보여주는 대시보드”가 아니라, Han Phillip의 실제 의사결정에 도움이 되는 “업무형 리스크 인텔리전스 허브”로 설계해야 합니다. 따라서 최종 판단 기준은 다음 7가지입니다. 첫째, 업무 의사결정 기여도 가장 중요한 기준은 각 기능이 실제 업무 판단에 직접 기여하는지입니다. 우선순위가 높은 기능: - 언더라이팅 리스크 판단에 영향을 주는 지정학, 제재, 전쟁, 항만, 해상운송, 선박 노출 정보 - 한국 주식 투자 판단에 필요한 이벤트, 섹터 민감도, 가격 반응, 거래대금, 상대강도 정보 - 뉴스의 단순 요약이 아니라 “그래서 지금 무엇을 봐야 하는가”를 제시하는 기능 - 과거 예상과 실제 결과를 비교해 판단 품질을 개선할 수 있는 기능 우선순위가 낮은 기능: - 보기에는 화려하지만 의사결정에 직접 연결되지 않는 일반 뉴스 피드 - 출처, 시점, 신뢰도 구분 없이 모은 단순 기사 목록 - 사용자가 다시 해석해야만 하는 원자료 나열형 화면 둘째, 출처와 최신성의 추적 가능성 모든 핵심 인텔리전스는 출처, 시각, 확인 상태가 분리되어야 합니다. 필수 표시 항목: - 원문 출처 - 보도 또는 데이터 기준 시각 - 수집 시각 - 확인된 사실인지, 추론인지, 미확인 주장인지 - 보도 간 충돌 여부 - 후속 확인 필요 여부 이 기준을 충족하지 못하는 정보는 핵심 판단 영역에 올리지 말고 “미확인 신호” 또는 “관찰 필요”로 분류해야 합니다. 셋째, 이벤트와 영향의 분리 뉴스 이벤트와 시장·언더라이팅 영향을 바로 인과관계로 연결하면 안 됩니다. 허브는 다음 구조로 정보를 보여줘야 합니다. - 발생 이벤트: 무엇이 일어났는가 - 관련 노출: 어떤 선박, 항로, 국가, 업종, 기업, 보험계약 또는 포트폴리오가 연결되는가 - 가능한 영향: 보험 리스크, 운임, 원자재, 환율, 주식 섹터, 지정학 리스크에 어떤 영향을 줄 수 있는가 - 검증 지표: 실제 가격, 거래대금, 선박 이동, 항만 지연, 제재 발표, 클레임 가능성 등 무엇으로 확인할 것인가 - 판단 상태: 관찰, 주의, 경계, 실행 검토, 보류 중 어디에 해당하는가 특히 한국 주식 영역에서는 “뉴스 때문에 주가가 움직였다”고 단정하지 않고, “가설”과 “검증 지표”로 관리해야 합니다. 넷째, 언더라이팅 관점의 실무 적합성 사용자의 직무가 해상보험 언더라이터라는 점을 기준에 반영해야 합니다. 우선 구현해야 할 언더라이팅 관점: - 선박 위치와 항로 리스크 - 제재·전쟁·항만 폐쇄·해협 봉쇄 가능성 - War risk, piracy, sanctions, cargo accumulation, delay risk, deviation risk - 특정 지역에 묶이거나 지연된 선박 목록 - 한국 관련 선박 또는 한국 기업 관련 노출 - 보험 인수 조건, 추가 보험료, 제외 조항, 모니터링 필요 여부에 대한 시사점 특히 사용자가 별도로 중요하게 보는 이란·호르무즈·페르시아만 관련 약 24척 한국 연계 선박은 별도 추적 객체로 관리하는 것이 타당합니다. 다섯째, 시각화의 목적성 시각화는 예쁘게 보이기 위한 것이 아니라, 위험의 위치·방향·강도·변화를 빠르게 판단하게 해야 합니다. 우선순위 높은 시각화: - 지도 기반 리스크 레이어: 해협, 항만, 분쟁 지역, 선박 위치, 항로 우회 - 타임라인: 사건 발생, 정책 발표, 시장 반응, 선박 이동, 보험 리스크 변화 - 리스크 매트릭스: 발생 가능성 × 영향도 - 섹터 민감도 맵: 뉴스 이벤트별 수혜·피해 가능 섹터 - 선박/계약 노출 보드: 지역별, 선종별, 보험종목별 노출 - 예상 대 실제 비교: 과거 브리핑의 전망과 이후 실제 결과 비교 - 신뢰도 표시: 확인된 사실, 추론, 미확인, 충돌 보도 구분 후순위 시각화: - 단순 워드클라우드 - 일반 기사 카드 나열 - 근거 없는 감성 점수 - 사용자의 다음 행동과 연결되지 않는 KPI 여섯째, 자동화와 인간 승인 경계 허브는 자동으로 수집·요약·분류·시각화할 수 있어야 하지만, 다음 행위는 반드시 사용자 승인 후 진행해야 합니다. 승인 필요: - 실제 파일 구조 변경 - 크론 작업 생성·수정·삭제 - 외부 메시지 발송 - 투자 판단 또는 매매 제안의 확정 표현 - 보험 인수 조건 변경을 암시하는 최종 권고 - 외부 API 비용이 발생하는 대량 수집 - 배포 또는 서비스 재시작 자동 수행 가능: - 공개 정보 조사 - 회의록 요약 - 판단 기준 작성 - 백로그 초안 작성 - 테스트 기준 작성 - 데이터 모델 제안 - 화면 설계 초안 작성 - 승인 전 실행 계획 작성 일곱째, 누적 학습 가능성 허브의 장기 가치는 “오늘의 요약”보다 “판단 품질의 개선”에 있습니다. 따라서 모든 주요 리포트는 다음을 남겨야 합니다. - 당시 판단 - 핵심 근거 - 불확실성 - 관찰 지표 - 예상 시나리오 - 실제 결과 - 예상과 실제의 차이 - 다음 판단 기준의 수정점 이 구조가 있어야 뉴스, 투자, 언더라이팅 판단이 시간이 지날수록 좋아집니다. 3. 의사결정 메모 의사결정 제목: Risk intelligence hub 고도화 방향에 대한 최종 판단 기준 의사결정 상태: 조건부 승인 권고. 단, 실제 구현·배포·크론 변경·외부 발송은 별도 승인된 후속 작업으로 분리한다. 핵심 판단: Risk intelligence hub는 단순 뉴스 대시보드가 아니라, Han Phillip의 해상보험 언더라이팅, 한국 주식 투자, 지정학 리스크 모니터링, 내부 지식 축적을 연결하는 업무형 인텔리전스 허브로 발전시켜야 한다. 최우선 방향: - 뉴스 수집보다 “판단 가능한 리스크 구조화”를 우선한다. - 모든 정보는 사실, 추론, 가정, 미확인 주장, 권고를 분리한다. - 시각화는 지도, 타임라인, 리스크 매트릭스, 선박/항로 노출, 섹터 민감도 중심으로 설계한다. - 투자 판단은 확정적 매매 신호가 아니라 가설과 검증 지표로 관리한다. - 언더라이팅 판단은 선박, 항로, 제재, 전쟁, 항만, 보험조건 영향을 중심으로 관리한다. - 과거 예상과 실제 결과를 비교하는 구조를 반드시 포함한다. 승인할 수 있는 1차 제품 방향: 1. 통합 리스크 대시보드 - 최신뉴스, AI뉴스/논문, 미국·이란/중동 리스크, 한국주식, 언더라이팅 리스크를 같은 허브 안에서 볼 수 있게 한다. - 단, 모든 주제를 동일한 방식으로 보여주지 않고, 각 주제별 판단 지표를 다르게 둔다. 2. 지정학·해상 리스크 보드 - 이란, 호르무즈, 페르시아만, 홍해, 흑해 등 핵심 해상 리스크 지역을 우선 대상으로 한다. - 선박 지연, 항로 변경, 제재, 군사 충돌, 항만 폐쇄 가능성을 타임라인과 지도 중심으로 표현한다. 3. 언더라이팅 인사이트 패널 - 리스크 변화가 보험 인수에 주는 의미를 별도 섹션으로 둔다. - 예: 추가 확인 필요, 인수조건 검토, war risk 주의, 제재 확인 필요, 특정 항로 exposure 점검 등. 4. 한국 주식 이벤트 반응 패널 - 뉴스 이벤트와 주가 반응을 분리해서 표시한다. - 섹터별 수혜·피해 가능성은 가설로 표시하고, 실제 거래대금·상대강도·가격 반응으로 검증한다. 5. 판단 품질 회고 기능 - 주요 브리핑마다 “예상”, “관찰 지표”, “실제 결과”, “오차 원인”을 남긴다. - 향후 expected-vs-actual 분석을 통해 리포트 품질을 개선한다. 보류해야 할 항목: - 실시간 자동 매매 또는 매매 권고 - 검증되지 않은 기사 기반의 강한 투자 결론 - 출처 없는 위험 점수 - 사용자 승인 없는 크론·외부 발송·배포 - 선박 위치·보험 노출 등 민감 데이터의 외부 공유 - 웹앱 내부 데이터 구조를 확인하지 않은 상태의 직접 구현 착수 4. 우선순위 제안 1순위: 의사결정 구조와 데이터 모델 확정 이유: 먼저 어떤 판단을 저장하고 보여줄지 정해야 시각화와 자동화가 흔들리지 않습니다. 포함 항목: - 리스크 이벤트 - 출처 - 신뢰도 - 영향 영역 - 관련 선박/국가/섹터 - 언더라이팅 시사점 - 투자 가설 - 검증 지표 - 후속 확인 항목 - 예상 대 실제 결과 2순위: 핵심 화면 설계 이유: 사용자가 매일 보는 화면이므로, 정보 구조가 업무 흐름과 맞아야 합니다. 우선 화면: - 오늘의 핵심 리스크 - 해상/지정학 지도 - 이벤트 타임라인 - 언더라이팅 영향 카드 - 한국주식 이벤트 반응 - 선박/항로 모니터링 - 예상 대 실제 회고 3순위: 뉴스·리포트 수집 파이프라인 정비 이유: 수집 자동화는 필요하지만, 판단 구조 없이 수집량만 늘리면 노이즈가 증가합니다. 우선 수집 대상: - 주요 국제 뉴스 - 해운·보험·제재 관련 자료 - 한국 시장 뉴스 - 공시·정책·거래 데이터 - 선박/항로 관련 공개 정보 4순위: 알림과 크론 이유: 알림은 강력하지만 과하면 피로도가 높습니다. 먼저 중요도 기준이 필요합니다. 권장: - 텔레그램은 10줄 내외의 executive alert - 상세 내용은 내부 웹앱 링크로 이동 - 중요도 낮은 경우 “중대 업데이트 없음” 허용 - 중대 리스크만 즉시 알림 5순위: 고급 분석과 자동 회고 이유: 초기에는 규칙 기반 구조화가 더 안정적입니다. 이후 데이터가 쌓이면 자동 회고와 패턴 분석을 강화합니다. 5. 필요한 권한 및 데이터 현재 단계에서는 외부 권한 없이 판단 기준과 의사결정 메모 작성은 완료했습니다. 다음 단계에서 실제 실행하려면 아래 권한 또는 확인이 필요합니다. 필요 권한: - unified-report-webapp 저장소 또는 배포 환경 수정 승인 - 웹앱 DB 스키마 변경 승인 - 크론 작업 생성·수정 승인 - 텔레그램 또는 기타 외부 발송 승인 - 외부 API 사용 시 비용·키 사용 승인 - 민감한 선박/보험 관련 데이터 사용 범위 확인 필요 데이터: - 현재 Risk intelligence hub의 실제 화면 구조 - 현재 저장되는 리포트/뉴스/크론 결과의 데이터 형식 - 기존 주제 분류: 최신뉴스, AI뉴스/논문, 미국이란전쟁, 한국주식 등 - 선박 추적 데이터의 출처와 접근 가능성 - 한국 주식 데이터 소스 - 사용자가 매일 확인하고 싶은 핵심 의사결정 질문 6. 검증 기준 이번 의사결정 메모의 검증 기준은 다음과 같습니다. 완료 검증: - 뉴스, 투자, 언더라이팅, 시스템 구현 관점이 모두 반영되었는가: 충족 - 실제 실행과 논의/계획이 분리되었는가: 충족 - 외부 부작용이 있는 작업을 수행했다고 허위로 말하지 않았는가: 충족 - 최종 판단 기준이 후속 backlog로 전환 가능할 만큼 구체적인가: 충족 - 사용자의 업무 맥락, 특히 해상보험 언더라이팅과 한국주식 관점이 반영되었는가: 충족 - 시각화 방향이 단순 디자인이 아니라 의사결정 목적과 연결되었는가: 충족 추가 검증 필요: - 실제 웹앱 구조와 현재 DB/API가 이 방향을 수용할 수 있는지 확인 필요 - 기존 리포트 데이터가 판단 기준별 필드를 충분히 갖고 있는지 확인 필요 - 선박 추적 데이터의 신뢰도와 접근 가능성 확인 필요 - 한국 주식 데이터의 자동 수집 가능 범위 확인 필요 7. 남은 블로커 블로커 1: 현재 웹앱의 실제 코드, DB 스키마, 화면 구조를 이 작업 안에서는 확인하지 않았습니다. 필요한 다음 확인: - unified-report-webapp 코드와 API 구조 점검 - 현재 리포트 저장 포맷 확인 - council/action item 저장 구조 확인 정확한 다음 명령 예시: cd /root/.openclaw/workspace/unified-report-webapp && find . -maxdepth 3 -type f | sort | head -200 단, 실제 점검은 코드 분석 작업으로 별도 승인 후 수행하는 것이 적절합니다. 블로커 2: 선박 위치 및 한국 연계 선박 데이터의 출처가 확정되지 않았습니다. 필요한 확인: - 공개 AIS 데이터 사용 여부 - 기존 vessel-tracker와 연동 가능 여부 - 보험/업무상 민감 데이터 포함 여부 - 외부 공유 제한 여부 블로커 3: 투자 데이터는 자동 수집·분석 가능하더라도 투자 판단으로 오해되지 않도록 표현 정책이 필요합니다. 필요한 기준: - “관찰” - “가설” - “검증 필요” - “투자 아이디어” - “매수/매도 권고 아님” 위 표현 체계를 웹앱에 명확히 반영해야 합니다. 블로커 4: 알림 정책이 아직 확정되지 않았습니다. 결정 필요: - 어떤 이벤트가 즉시 알림 대상인지 - 어떤 이벤트는 일일/정기 리포트로 충분한지 - “중대 업데이트 없음”을 어떤 기준으로 허용할지 - 텔레그램 알림과 웹앱 상세 보고서의 분량 차이 8. 권고되는 다음 실행 항목 다음 action item으로 분리하는 것을 권고합니다. 1. Code Senior 담당: 제품/시스템 반영 항목을 backlog와 테스트 기준으로 정리 산출물: - 기능 백로그 - 데이터 모델 초안 - API 변경 후보 - 화면별 컴포넌트 목록 - 테스트 기준 2. News Agent 담당: 뉴스·리스크 데이터의 출처, 최신성, 신뢰도 분류 체계 제안 산출물: - 출처 등급 - timestamp 정책 - 미확인 주장 표시 방식 - 충돌 보도 처리 기준 3. KR Invest 담당: 한국주식 이벤트 반응 분석 프레임 작성 산출물: - 섹터 민감도 분류 - 거래대금/상대강도 검증 기준 - 이벤트 전후 가격 반응 분리 기준 - 투자 권고 오해 방지 문구 4. Main Orchestrator 담당: 최종 통합 보고서 작성 산출물: - 의사결정 요약 - 단계별 실행 로드맵 - 승인 필요 항목 - 리스크 및 보류 항목 - 예상 대 실제 회고 설계 9. 최종 결론 Risk intelligence hub 고도화는 진행 가치가 높습니다. 다만 성공 기준은 “정보를 많이 모으는 것”이 아니라 “Han Phillip이 더 빠르고 정확하게 업무 판단을 내릴 수 있게 하는 것”입니다. 따라서 최종 의사결정 기준은 다음 한 문장으로 정리할 수 있습니다. “출처와 최신성이 검증된 정보를 바탕으로, 뉴스·선박·시장·언더라이팅 영향을 분리해 구조화하고, 지도·타임라인·리스크 매트릭스·섹터 반응·예상 대 실제 비교를 통해 사용자의 실제 판단을 개선하는 기능부터 우선 구현한다.” 현재 단계에서 의사결정 메모 작성은 완료되었습니다. 실제 구현, 파일 수정, 크론 변경, 외부 발송, 배포는 아직 수행하지 않았으며, 별도 승인된 후속 작업으로 진행해야 합니다.

완료된 작업 1. 현재 코드베이스 확인 - 대상 프로젝트를 `/root/.openclaw/workspace/unified-report-webapp`로 보고 확인했습니다. - `graphify-out/GRAPH_REPORT.md`, `graphify-out/graph.json`은 현재 없음. - 확인한 주요 파일: - `README.md` - `sketches/001-risk-intelligence-workbench/README.md` - `app/templates/dashboard.html` - `app/templates/council_detail.html` - `app/services/council_action_processor.py` - `tests/test_council.py` 2. 현재 시스템 상태 요약 - 앱은 FastAPI 기반 내부 Risk Intelligence Hub입니다. - 현재 기능: - Markdown/YAML frontmatter 기반 리포트 인덱싱 - 리포트/이벤트/토픽/카테고리 API - 리포트 상세 화면 - 대시보드 - 협의체 생성/진행/결과 생성/후속 작업 실행 요청 - 협의체 action item을 담당 agent에게 dispatch하고 결과를 transcript에 저장하는 구조 - 현재 UI 방향성은 `Risk Intelligence Workbench` 스케치에 이미 잡혀 있습니다: - 좌측 탐색 - 리포트 피드 - 우측 action queue - severity-coded risk chip - saved views/search/council start workflow 3. 안전하게 수행한 검증 - 전체 테스트 실행 완료: - 명령: `.venv/bin/pytest tests -q` - 결과: `41 passed in 42.10s` - 이번 작업에서는 코드/DB/크론/외부 API/자격증명 변경 없음. 제품/시스템 반영 backlog P0. 대시보드에 “위험 우선순위 큐” 추가 목표: - Han Phillip이 매일 가장 먼저 봐야 할 리스크를 자동 정렬해서 보여주는 운영 화면을 만든다. - 단순 최신순이 아니라 “업무 영향도” 기준으로 정렬해야 함. 반영 항목: - 각 report/event에 다음 필드를 표준화: - severity: low / medium / high / critical - urgency: today / this_week / watch - domains: news / underwriting / kr-invest / geopolitics / shipping - affected_assets: 선박, 항로, 국가, 섹터, 종목, 거래처 등 - confidence: confirmed / likely / speculative / unknown - next_action: 확인 필요 / 모니터링 / 협의체 필요 / 언더라이팅 검토 필요 - `/` dashboard의 “최근 인텔리전스” 영역을 “우선순위 큐”와 “최신 피드”로 분리. - high/critical은 상단 고정 또는 별도 섹션으로 노출. 테스트 기준: - severity가 critical인 리포트가 최신순보다 우선 노출되는지 확인. - severity가 없는 기존 리포트도 화면이 깨지지 않고 기본값 watch/unknown으로 표시되는지 확인. - API 테스트: - `/api/reports` 응답에 severity/urgency 필드가 있거나, 없는 경우 안전한 fallback이 적용되어야 함. - UI 테스트: - dashboard HTML에 critical/high badge가 표시되는지 확인. - 회귀 테스트: - 기존 `tests/test_api.py`, `tests/test_council.py` 전체 통과. P0. 협의체 action item을 backlog 객체로 승격 목표: - 현재 action item은 transcript 안의 후속 작업 성격이 강함. - 이를 실제 제품 backlog로 전환해 상태, 담당자, 테스트 기준, 완료 조건을 추적 가능하게 해야 함. 반영 항목: - council action item에 다음 필드 추가 검토: - priority - product_area - owner_agent_key - acceptance_criteria - verification_commands - blocker_notes - linked_report_slug - linked_event_id - status: proposed / dispatched / in_progress / completed / blocked / rejected - 협의체 상세 우측 action item 영역에 다음을 표시: - 우선순위 - 담당 agent - 실행 상태 - 검증 기준 요약 - 마지막 실행 결과 링크 - action result를 단순 메시지로만 남기지 말고 action item의 완료 증거로 연결. 테스트 기준: - action item 생성 시 acceptance_criteria가 비어 있어도 기존 흐름이 깨지지 않아야 함. - action dispatch 후 status가 `dispatched` 또는 `completed`로 정확히 전환되어야 함. - agent 결과 메시지 metadata에 `kind=action_result`, `job_id`, `action_id`가 유지되어야 함. - 실패 시 action item이 무조건 completed가 되지 않고 blocked/failed evidence가 남아야 함. - 기존 테스트 `test_council_api_create_list_detail_intervention_and_close`, action dispatch 관련 테스트 확장 필요. P0. 리스크 이벤트 중심 화면 추가 목표: - 뉴스/투자/언더라이팅 리포트를 개별 문서가 아니라 “이벤트” 중심으로 묶어 판단할 수 있게 함. - 예: 호르무즈, 제재, 선박 억류, 전쟁, 금리, 특정 종목 이벤트. 반영 항목: - 이벤트 상세 화면에 다음 섹션 추가: - 핵심 타임라인 - 관련 리포트 - 관련 협의체 - 시장 반응 - 언더라이팅 영향 - 미확인 가정 - 다음 확인 항목 - 현재 README에 `/api/events`, `/events/{event_id}`가 있으므로 기존 이벤트 구조를 확장하는 방식이 적합. - 이벤트별 severity와 confidence를 리포트에서 집계. 테스트 기준: - 관련 리포트가 여러 개일 때 이벤트 상세에서 모두 연결되는지 확인. - 이벤트가 없는 리포트도 기존 리포트 화면에서 정상 노출되어야 함. - event_id가 없는 요청은 404로 안전 처리. - 이벤트 상세 HTML에 timeline, related reports, underwriting impact 섹션이 렌더링되는지 확인. P1. “출처·최신성·충돌 여부” evidence panel 추가 목표: - News Agent가 제안한 “사실관계·출처·최신성·보도 충돌”을 UI에서 바로 확인 가능하게 함. - 리스크 허브가 단순 요약 도구가 아니라 검증 가능한 intelligence hub가 되도록 함. 반영 항목: - report metadata에 다음 필드 권장: - source_url - source_name - source_published_at - collected_at - freshness_status: fresh / stale / unknown - corroboration_status: single_source / multi_source / conflicting / unverified - conflicting_claims - report detail 또는 event detail 우측에 evidence panel 추가. - 충돌 또는 미확인 주장은 빨간색 경고가 아니라 “검증 필요” 상태로 표현. 테스트 기준: - source_url이 없는 내부 메모도 화면이 깨지지 않아야 함. - conflicting 상태인 리포트는 evidence panel에 “충돌/검증 필요”로 표시되어야 함. - 오래된 리포트는 freshness_status가 stale로 표시되는지 확인. - Markdown frontmatter 파싱 실패가 전체 인덱싱을 중단하지 않아야 함. 기존 diagnostics 정책 유지. P1. 투자/시장 반응은 “가설”로만 연결 목표: - KR Invest 관점의 핵심 원칙 반영: 뉴스와 주가 반응을 인과로 단정하지 않음. - 가격 반응은 “후속 검증 지표”로 분리. 반영 항목: - event detail에 market hypothesis 섹션 추가: - 관련 섹터 후보 - 관련 종목 후보 - 거래대금 변화 - 상대강도 - 뉴스 전 추세 vs 뉴스 후 반응 - 검증 상태 - 종목/섹터 정보는 투자 판단이 아니라 관찰 대상 watchlist로 표시. - “수혜/피해” 단정 표현 대신 “민감도 후보”, “확인 필요” 표현 사용. 테스트 기준: - market hypothesis 섹션이 없더라도 이벤트 화면 정상 렌더링. - hypothesis 항목은 recommendation이 아니라 observation/provisional label로 저장. - 화면 문구에 “매수/매도 추천”처럼 투자 판단으로 오해될 수 있는 표현이 들어가지 않도록 테스트 또는 스냅샷 점검 필요. P1. 언더라이팅 영향 매트릭스 추가 목표: - Han Phillip의 실제 업무 맥락에 맞춰 뉴스/이벤트가 보험 인수 판단에 미치는 영향을 구조화. - 단순 뉴스 요약이 아니라 “보험자 노출이 어떻게 달라지는가”를 보여줘야 함. 반영 항목: - event/report detail에 underwriting impact matrix 추가: - risk transfer impact - claims handling impact - sanctions/legal impact - trading limit impact - accumulation/exposure impact - wording implication - required follow-up documents - Markdown Mermaid 또는 HTML 카드 방식으로 표시 가능. - 기존 README에 Mermaid 렌더링 지원이 있으므로 초기 구현은 Mermaid risk matrix를 활용해도 됨. 테스트 기준: - underwriting 필드가 없는 일반 뉴스 리포트에서도 화면 정상. - underwriting impact가 있는 리포트는 matrix 섹션 렌더링. - Mermaid code fence가 기존 report detail에서 정상 렌더링되는지 회귀 확인. - 보험 관련 섹션은 “사실/추론/가정/권고” 구분을 유지. P1. Saved views / 필터 프리셋 목표: - 매번 검색 조건을 새로 고르지 않고, 업무 모드별 화면을 빠르게 열 수 있게 함. 반영 항목: - 기본 saved views: - 오늘의 high severity - 호르무즈/해상운송 - 제재/전쟁/지정학 - 한국주식 이벤트 - 언더라이팅 검토 필요 - 협의체 action item 미완료 - URL query 기반으로 먼저 구현: - `/reports?view=high-severity` - `/reports?domain=underwriting&urgency=today` - `/events?severity=critical` - DB 저장형 개인화 saved view는 후순위. 테스트 기준: - view 파라미터가 잘못 들어와도 기본 목록으로 fallback. - 각 saved view가 기대 필터 조건을 적용. - 기존 `/reports` 기본 목록 동작 유지. P2. Action queue 중심의 업무 cockpit 목표: - 리포트 읽기와 협의체 실행 이후 남은 할 일을 한 화면에서 관리. - “무엇을 확인해야 하는가”가 대시보드에서 바로 보여야 함. 반영 항목: - dashboard 우측 rail에 action queue 추가: - blocked - dispatched - pending verification - completed today - 각 action item에 “재실행”, “검증 완료”, “차단 사유 기록” 버튼은 후속 단계로 검토. - 최초 버전은 읽기 전용 목록만 충분. 테스트 기준: - action item이 없는 경우 빈 상태 문구 표시. - blocked 항목이 상단에 표시. - action result가 연결된 completed 항목은 transcript 링크를 제공. P2. 운영 진단/품질 화면 강화 목표: - 내부 도구라도 데이터 누락, 파싱 실패, 중복 slug, 오래된 인덱스 상태를 쉽게 확인해야 함. 반영 항목: - 기존 `/api/diagnostics`를 UI로 노출. - 표시 항목: - 총 리포트 수 - 마지막 reindex 시간 - malformed files - duplicate slugs - source root별 파일 수 - 최근 action job 실패 - 운영자가 바로 실행할 수 있는 next command 안내: - reindex - smoke test - backup - restore 테스트 기준: - diagnostics API가 malformed file을 반환할 때 UI에서 안전하게 렌더링. - duplicate slug가 있을 때 경고 표시. - `/api/diagnostics` 실패 시 대시보드 전체가 깨지지 않아야 함. 구현 순서 제안 1단계: 데이터 계약 고정 - severity, urgency, confidence, evidence, action item verification 필드 정의. - 기존 Markdown frontmatter와 DB action item 구조 중 어디에 저장할지 결정. - 완료 기준: - 샘플 frontmatter 3개 작성 - action item schema 변경 필요 여부 결정 - 기존 리포트 호환성 정책 확정 2단계: 읽기 전용 UI부터 구현 - dashboard 우선순위 큐 - report/event evidence panel - action queue 읽기 전용 - 완료 기준: - 기존 DB/문서에 destructive migration 없이 동작 - 누락 필드 fallback 처리 - 기존 테스트 전체 통과 3단계: 협의체 action item 확장 - acceptance criteria, verification command, blocker notes 저장. - action result를 action item 완료 증거로 연결. - 완료 기준: - dispatch 성공/실패/재시도 테스트 추가 - transcript와 action item 상태가 불일치하지 않음 4단계: 이벤트 중심 intelligence view - event detail을 리스크 판단 화면으로 확장. - timeline, related reports, market hypothesis, underwriting impact 추가. - 완료 기준: - 이벤트 없는 리포트 호환 - 이벤트 여러 개 연결되는 리포트 처리 - UI smoke test 통과 5단계: 운영 안정화 - diagnostics UI - smoke test 강화 - 배포 전 backup/reindex runbook 정리 - 완료 기준: - `.venv/bin/pytest tests -q` 통과 - `deploy/smoke-test.sh` 통과 - DB 백업 후 재시작 검증 필요한 권한/데이터 현재 이 action item은 분석/계획 정리이므로 추가 권한 없이 완료했습니다. 실제 구현에 들어가려면 다음 결정이 필요합니다. 1. 저장 방식 결정 - 선택 A: Markdown frontmatter 중심 - 장점: 리포트와 메타데이터가 함께 이동 - 단점: action item처럼 상태가 바뀌는 데이터에는 부적합 - 선택 B: SQLite DB 중심 - 장점: action queue/status 관리에 적합 - 단점: 문서 원본과 메타데이터 분리 - 권장: - report/event의 분석 메타데이터는 frontmatter 우선 - action item/status/job result는 SQLite DB 우선 2. 외부 데이터 연동 여부 - 뉴스 원문 freshness/source check, 시장 가격/거래대금 확인은 외부 API 또는 크롤러 권한이 필요합니다. - 이 작업에서는 외부 API 호출 또는 credentials 사용 안 했습니다. - 실제 연동 전 필요한 확인: - 사용할 뉴스 소스 - 시장 데이터 소스 - API key 보관 방식 - 호출 주기 - 실패 시 fallback 정책 3. 배포 반영 권한 - systemd 재시작, cron 변경, DB migration은 외부/운영 side effect에 해당합니다. - 승인 후 실행할 명령 후보: - 테스트: `cd /root/.openclaw/workspace/unified-report-webapp && .venv/bin/pytest tests -q` - 스모크 테스트: `cd /root/.openclaw/workspace/unified-report-webapp && deploy/smoke-test.sh` - DB 백업: `cd /root/.openclaw/workspace/unified-report-webapp && deploy/backup-db.sh` - 운영 재시작: `cd /root/.openclaw/workspace/unified-report-webapp && deploy/restart-prod.sh` 남은 blocker 1. 실제 risk metadata schema 미확정 - severity, urgency, confidence, evidence, underwriting impact를 어떤 exact schema로 둘지 아직 결정 필요. 2. 이벤트와 리포트 연결 규칙 미확정 - linked_events frontmatter 기반인지, 태그/slug 자동 추론인지 결정 필요. - 자동 추론은 편하지만 오탐 가능성이 있으므로 초기에는 명시 연결을 권장. 3. 시장 데이터 연동 범위 미확정 - KR Invest 관련 가격/거래대금/상대강도는 현재 action item 범위에서는 실제 조회하지 않았습니다. - 별도 kr-invest profile 또는 데이터 파이프라인과 연동해야 합니다. 4. 운영 DB migration 여부 미확정 - action item 확장은 DB schema 변경 가능성이 있습니다. - 운영 DB 백업 및 migration 테스트 승인 필요. 검증 수행한 검증: - 프로젝트 위치 확인 완료. - Graphify 산출물 없음 확인. - 현재 README/API/UI/협의체 action processor/test 구조 확인 완료. - 테스트 실행 완료: - `.venv/bin/pytest tests -q` - 결과: `41 passed in 42.10s` 검증하지 않은 항목: - 운영 서버 재시작 안 함. - 실제 브라우저 UI 접속 테스트 안 함. - 외부 뉴스/시장 API 호출 안 함. - DB migration 안 함. - 크론/systemd 변경 안 함. 최종 권고 제품 반영은 “대시보드 우선순위 큐 + 협의체 action item backlog화 + evidence panel”을 P0로 묶어 1차 구현하는 것이 가장 실용적입니다. 이유: - 현재 앱 구조와 가장 잘 맞습니다. - 외부 API 없이도 기존 리포트/협의체 데이터만으로 구현 가능합니다. - Han Phillip의 실제 사용 흐름인 “읽기 → 판단 → 협의체 → 후속 작업 → 검증”을 끊김 없이 연결합니다. - 투자/뉴스/언더라이팅을 한 화면에 합치되, 인과 단정과 미확인 주장을 분리할 수 있습니다.