hanarang-dashboard/.plans/design/ui/dashboard-design.md

대시보드 메인 (/) — Sprint 015 Master Dashboard v3

목적

대시보드 메인은 단순 요약 화면이 아니라, 자기야가 들어오자마자 지금 4자매 파이프라인이 어디까지 와 있는지 즉시 판단할 수 있는 대표 운영 화면이어야 해.

이번 v3의 핵심은 현행 미니멀 터미널 UI를 유지하면서, 더 강한 정보 구조와 흐름 시각화로 메인 화면을 재구성하는 것이야.

유지할 것

• 현재 제품의 미니멀 터미널 톤
• 짙은 배경 + 얇은 border + mono 보조 텍스트
• 4자매 중심 세계관/역할 구분
• 모바일 하단 탭바와 기존 페이지 동선

강하게 가져올 것

• 상단 global status bar 구조
• 4자매 카드 1행 배치
• ACTIVE PIPELINE 중심 운영 다이어그램
• ACTIVITY FEED + SPRINT METRICS 병렬 구조
• INFRASTRUCTURE OVERVIEW + MISTAKE LOG & HARNESS 하단 운영 패널 구조

줄일 것

• 과한 glow
• 장식성 애니메이션 남발
• 의미 없이 많은 뱃지/배경 장식
• mock 대시보드처럼 보이는 가짜 숫자 강조

---

전체 레이아웃

1. Top Global Status Bar

한 줄 또는 반응형 2단 구조.

좌측

• 브랜드/제품명
• 현재 페이지 정체성 (Master Dashboard)

중앙

• 현재 Sprint / Day / focus summary
• 진행률 bar 또는 current cycle 요약

우측

• Discord/Runtime 연결 상태
• 알림 진입점
• operator/avatar 요약

UX 기준

• 상단에서 현재 운영 국면을 짧게 읽을 수 있어야 함
• 모바일에서는 좌/중/우를 무리하게 한 줄에 우겨넣지 말고 2단으로 자연스럽게 접기

---

2. Sister Status Cards Row

4자매 카드는 1행 핵심 상태 영역.

공통 정보

• 이름
• 역할
• 상태 (IDLE, WORKING, REVIEWING, OFFLINE, DEPLOYING 등)
• CPU / RAM 또는 대응 리소스 지표
• 현재 작업 한 줄 요약

역할별 색 기준

• Harang: amber
• Narang: sky
• Darang: pink
• Irang: violet

상태 표현 규칙

• 색은 역할 + 현재 상태를 같이 전달해야 함
• working/reviewing처럼 active 상태일 때만 강한 강조
• idle은 조용하게
• offline은 회색/경고 계열로 분명히 구분

카드 UX 기준

• 네 카드의 높이/구조는 최대한 동일
• 긴 텍스트는 1줄 또는 2줄 clamp
• CPU/RAM은 숫자와 bar를 함께 보여줘도 되지만 과장하지 말 것
• 아바타/아이콘은 보조 요소고, 상태 텍스트가 주인공이어야 함

---

3. ACTIVE PIPELINE

이번 v3의 대표 섹션.

목적

User → Harang → Narang → Darang → Irang 흐름과, maker-checker loop, escalation 조건을 한눈에 보여준다.

기본 노드

• User
• Harang (Plan & Assign)
• Narang (Implement or active task id)
• Darang (Review / QA)
• Irang (Deploy / Idle)

보여줄 정보

• 현재 active task 또는 ticket id
• Narang ↔ Darang review loop
• escalation 조건 또는 누적 실패 횟수
• Irang이 아직 idle인지, redeploy 대기인지

구현 기준

• SVG 기반 라인/화살표 허용
• active state가 있을 때만 제한적 pulse/flow
• 정적인 설명보다 실제 운영 상태가 우선
• loop / escalation은 읽히되 과하게 복잡하면 안 됨

금지

• 예쁘기만 한 다이어그램
• 현재 상태를 읽을 수 없는 장식형 선/화살표

---

4. Middle Row — ACTIVITY FEED + SPRINT METRICS

운영 근거와 정량 판단을 나란히 배치한다.

A. Activity Feed

운영 이벤트 타임라인.

우선 정보

• 시각
• 주체/대상 (예: Narang → Darang)
• 이벤트 타입 (handoff, review_request, review_fail, deploy, hotfix 등)
• 관련 task/sprint/hotfix id
• 실패/경고 시 짧은 원인

UX 기준

• 텍스트 로그가 아니라 읽히는 이벤트 카드여야 함
• event type 색은 통일감 있게 관리
• 필요하면 details/JSON 결과는 접어서 보여줌

B. Sprint Metrics

한 Sprint의 진행 체감치를 운영 지표로 압축.

포함 후보

• total tasks
• done / in progress / review / planning 비중
• sister별 completed count
• avg iterations
• first-pass rate
• escalation count

UX 기준

• 차트는 보조, 숫자 읽기가 우선
• donut + mini bar + stat box 조합 허용
• 활동 피드와 같은 행에서 비교했을 때 자연스러워야 함

---

5. Bottom Row — INFRASTRUCTURE OVERVIEW + MISTAKE LOG & HARNESS

운영 기반과 학습 자산을 하단에 둔다.

A. Infrastructure Overview

목적

현재 시스템이 어디서 어떻게 돌아가는지 빠르게 파악.

포함 요소

• gateway
• sisters runtime host/lxc/vm
• deploy access path
• health / load / uptime 요약

표현 방식

• 단순 카드 나열보다 연결 관계가 보이는 가벼운 맵 구조 선호
• 다만 실제 데이터가 빈약하면 과장된 네트워크 다이어그램으로 만들지 말 것

B. Mistake Log & Harness

목적

운영 중 쌓인 실수/규칙/학습 자산을 한 눈에 보여줌.

포함 요소

• 최신 mistake/harness rule 몇 개
• 작성 시점
• 누가 추가했는지
• category (DB Schema, Frontend, Deployment 등)
• 필요하면 작은 trend visualization

UX 기준

• 단순 문서 링크가 아니라 운영 학습 보드처럼 보여야 함
• View Full 또는 상세 문서 링크는 보조로 유지

---

데스크톱 정보 순서

1. Top Global Status Bar
2. Sister Status Cards
3. Active Pipeline
4. Activity Feed / Sprint Metrics
5. Infrastructure Overview / Mistake Log & Harness

모바일 정보 순서

1. Top Status Summary
2. Sister Status Cards (2열 또는 1열)
3. Active Pipeline
4. Activity Feed
5. Sprint Metrics
6. Infrastructure Overview
7. Mistake Log & Harness

모바일에서는 복잡한 수평 관계보다 세로 읽기 흐름이 우선이야.

---

데이터 연결 원칙

• mock 텍스트/숫자로 고정하지 말고 실제 데이터가 들어올 자리를 먼저 설계할 것
• 값이 없을 때는 No recent activity, No active deployment, No harness rules yet처럼 조용한 empty state 제공
• offline / missing / unavailable 상태는 숨기지 말고 명확히 드러낼 것
• websocket 연결 상태와 데이터 freshness를 같은 의미로 쓰지 말 것
• 각 섹션은 가능하면 아래 source 중 하나로 구분할 것
  • runtime live
  • event mirrored
  • polling snapshot
  • doc derived
  • empty / unavailable
• 추정/합성값이면 사실처럼 단정하지 말고 neutral wording 사용

카피 원칙

• 설명문보다 라벨형 문구 우선
• 첫 화면 문구는 짧고 건조해야 함
• ~만들었어, ~정리했어, ~읽히게 같은 메타 설명 금지
• 보드/패널 body는 원문 요약 또는 상태 문구 위주로 짧게 유지

인터랙션 원칙

• hover 없어도 핵심 정보가 읽혀야 함
• 클릭 가능한 영역은 페이지 이동 또는 상세 패널 열기처럼 의미가 분명해야 함
• notification / details / expand는 보조 수단

스타일 원칙

• background는 현행 다크 톤 유지
• border 1px 중심
• 그림자/glow는 active state 강조용 최소치만 사용
• 하드한 터미널 감성과 현대적 운영 패널 느낌 사이 균형 유지

연결 페이지

• 프로젝트 페이지는 phase/QA/deploy 세부 판단용
• 활동 페이지는 장기 로그 열람용
• 자매 상세는 개별 runtime/세션 분석용
• 관리 페이지는 조작/재시작/관리용

즉, 홈은 모든 걸 다 보여주는 곳이 아니라 지금 어디를 눌러야 하는지 판단시키는 운영 출발점이어야 해.