vtuber-dashboard

name	vtuber-dashboard
description	AUTORIG 검수 관제탑(control_tower, 8095)이 "지금 돌아가는 파이프라인을 정확히 비추는 상태"인지 최신화·검증한다. 관제탑은 runs/<id>/events.jsonl을 라이브로 읽어 프론트가 폴링하므로 데이터는 본질적으로 최신이다 — 진짜 드리프트 리스크는 ① 서버 미기동 ② 스테이지 등록 3곳 비동기 ③ 신규 산출이 artifact_created로 발행 안 됨. 트리거 — "대시보드 최신화", "관제탑 최신화", "관제탑 켜줘", "대시보드 확인", "진행 대시보드 보여줘", "관제탑이 현재 런 보고 있나", "새 스테이지 대시보드 반영", "dashboard refresh", "control tower 동기화". 진단은 메인 모델이, 코드 동기화 편집은 Sonnet에 위임.

관제탑(검수 대시보드) 최신화

AUTORIG 풀런 진행을 주인님이 8095에서 실시간 검수·게이트 판정하는 화면이 현 파이프라인과 동기화돼 있는지 점검·복구한다. 서버: scripts/run_autorig_control_tower.py (events.jsonl → /api/* → 프론트 폴링). 프론트는 활성 런(RUNNING/GATE_WAITING)을 자동 추종한다(control_tower/src/app.js pickRun) — 런 선택은 무수정.

1. 데이터 수집 (결정론 — 추측 금지, 실제로 확인)

# ① 서버 살아있나
curl -s -o /dev/null -w "8095 -> %{http_code}\n" --max-time 4 http://127.0.0.1:8095/api/runs

# ② 현재 런을 1순위로 추종하나 (활성 런이 맨 위 RUNNING/GATE_WAITING여야)
curl -s --max-time 5 http://127.0.0.1:8095/api/runs \
  | python3 -c "import sys,json;[print(r['status'],r['run_id']) for r in json.load(sys.stdin)['runs'][:4]]"

# ③ 스테이지 등록 3곳 동기화 (이게 유일한 코드 드리프트 지점)
grep -n "STAGE_ORDER" scripts/autorig_events.py            # 이벤트 라이브러리
grep -n "^STAGES" scripts/run_autorig_pipeline.py          # 러너가 run_started에 싣는 권위 목록
grep -n "STAGE_LABELS" control_tower/src/app.js            # 프론트 한글 라벨(키 = 스테이지)

판정 핵심: 러너 STAGES의 모든 항목이 app.js STAGE_LABELS에 키로 존재해야 한다(라벨 누락 = 무명 박스). STAGE_LABELS가 더 많은 건 무해(여유 라벨). 신규 스테이지 추가 시 위 3곳 + 산출 artifact_created 발행을 함께 갱신한다.

2. 판정 기준

기준	좋음	나쁨 → 조치
서버	8095 200 응답	DOWN → §3 기동
런 추종	현재 풀런이 RUNNING/GATE_WAITING로 1순위	옛 런만 보임 → 새 런 시작됐는지 확인(자동추종이라 보통 무조치)
스테이지 동기	러너 STAGES ⊆ app.js STAGE_LABELS 키	라벨 누락 → §3 동기화
산출 가시화	신규 추출/리그 PNG가 Feed에 뜸	안 뜸 → 러너에 writer.artifact_created(path,label,stage) 추가

3. 조치

# 서버 기동 (이미 떠 있으면 생략 — 포트 충돌만 확인)
python3 scripts/run_autorig_control_tower.py --port 8095 --no-open   # 백그라운드로 실행
# 알림 끄려면 --no-notify, 게이트 macOS 알림은 기본 ON

• 스테이지 동기화 편집(라벨/순서 드리프트): 3곳을 일치시키는 편집은 Sonnet 서브에이전트에 위임 하되, 정확한 스테이지 키·한글 라벨·삽입 위치를 프롬프트에 명시(서브에이전트는 대화 맥락 없음).
• 신규 산출 가시화: 러너의 해당 스테이지 직후 writer.artifact_created(rel(path), label="한글", stage="Pn"). 관제탑은 runs/<id>/artifacts/로 복사·서빙하므로 Feed 썸네일에 자동 표시(app.js 아티팩트 핸들러).
• 프론트 변경 후: app.js/styles.css는 정적 서빙이라 브라우저 새로고침으로 반영(서버 재기동 불요).
• 좀비 런 정리(자주 필요): 죽인/실패한 풀런이 RUNNING/GATE_WAITING로 남으면, 현재 런이 닫힌 뒤 pickRun이 그 좀비를 따라가 엉뚱한 옛 런을 비춘다. 살아있는 프로세스 확인(pgrep -lf run_autorig_pipeline.py) 후, 거기 없는데 활성으로 남은 런에 정직한 종료 기록을 남긴다(run_state 직접 편집 아님 — 실제로 죽었으니):

  python3 -c "import sys;sys.path.insert(0,'scripts');from autorig_events import EventWriter;\
  EventWriter('<dead_run_id>').run_failed('프로세스 종료됨 — 좀비 정리')"
  

  현재 살아있는 런(게이트 대기 포함)은 절대 건드리지 말 것.

4. 가드레일 (박제된 교훈)

• 데이터는 events.jsonl이 SSOT — 관제탑은 읽기 전용 뷰다. "최신화"는 화면 데이터를 손대는 게 아니라 서버 기동 + 스테이지 라벨 동기 + 산출 발행 3가지뿐. 런 상태를 직접 편집하지 않는다.
• 자동추종을 신뢰(pickRun) — 런이 안 보이면 보통 "새 런이 아직 run_started 안 함"이지 대시보드 탓이 아니다. 먼저 runs/에 새 run_id가 생겼는지 확인하라.
• 게이트는 블로킹 — H1.5/H2에서 러너가 24h 대기한다. 대시보드가 멈춘 듯 보여도 정상(주인님 판정 대기).
• 진단은 curl/grep으로 사실만 — LLM 추측 금지([[visual-verify-real-render]] 정신: 실제 응답으로 판정).

생성/수정 후: 8095가 200을 주고 현재 런이 1순위로 뜨는지 curl로 재확인해 보고하라.