# task-2130: 봇 wake-up 메커니즘 안정성 개선

## ★ 프로젝트: `/home/jay/workspace/`

## 문제
dispatch.py로 팀에 작업 위임 시, 봇이 작업을 수신하지 못하는 경우가 반복 발생.
- task-2125: composite dispatch → 1팀 봇 수신했지만 2팀 봇에도 중복 위임 필요
- task-2126: 7팀 봇 미수신 → 수동 cron 재전송 필요
- task-2128: 4팀 봇은 정상 수신
- task-2129: 6팀 봇 세션은 열렸지만 "작업 지시를 기다리고 있습니다" 상태로 2분 대기 → 수동 재전송

## 현재 메커니즘 (dispatch.py L1306~1355)

### 2단계 wake-up
1. **Stage 1**: 봇 프로세스 없으면 → cokacdir로 세션 시작 메시지 전송
2. **Stage 2**: 15초 대기하며 봇 프로세스 시작 확인 (5초 × 3회)
3. **실패 시**: "딜레이 15초 후 작업 전송" — lazy-start 모드

### 문제점
- 봇 세션이 열리는 데 15~30초 걸리지만, cron은 absolute 시간으로 전송
- 세션이 열리기 **전에** cron 시간이 도달하면 → 봇이 cron을 수신 못 함
- 세션이 열린 후 "작업 지시를 기다리고 있습니다" 상태에서 → 이미 실행된 cron은 소실
- **근본 원인**: cron의 absolute 시간과 봇 세션 시작 시간의 race condition

## 수정 방향

### 방안 A: 봇 프로세스 확인 후 cron 전송 (권장)
```
1. wake-up 메시지 전송
2. 봇 프로세스 시작까지 대기 (최대 60초, 5초 간격 폴링)
3. 프로세스 확인 후 → cron 전송 (at "30s" 딜레이)
4. 60초 내 미시작 → 에러 로그 + 재시도 1회
```
→ 봇 프로세스가 확실히 살아있을 때 cron을 보내므로 race condition 해소

### 방안 B: 재시도 메커니즘 추가
```
1. cron 전송 후 30초 대기
2. 봇 프로세스에서 task 파일 접근 여부 확인 (heartbeat 체크)
3. 미확인 시 → cron 재전송 (최대 2회)
```

### 방안 C: cron 대신 세션 직접 메시지
```
1. 봇 세션이 열리면 자동으로 "작업 지시를 기다리고 있습니다" 상태
2. 이 세션에 /start 9B378691 같은 명령으로 이전 cron workspace에 연결
3. 또는 새 cron을 열린 세션에 직접 전송
```

## ★ 먼저 읽을 파일
- `/home/jay/workspace/dispatch.py` — L1306~1355 (_wake_up_bot 함수)
- `/home/jay/workspace/dispatch.py` — lazy-start 관련 코드 (grep "lazy" dispatch.py)
- `/home/jay/.cokacdir/docs/` — cokacdir cron 명령어 동작 방식

## 검증 시나리오 (이게 되면 성공)

### 시나리오 1: 슬립 상태 봇에 dispatch
1. 모든 봇 프로세스가 없는 상태에서 dev5-team에 테스트 작업 dispatch
2. 봇 세션 시작 → 작업 수신 → 정상 실행
3. 수동 재전송 불필요

### 시나리오 2: 연속 dispatch
1. dev1-team에 작업 A dispatch → 완료
2. 즉시 dev1-team에 작업 B dispatch
3. 봇이 작업 B를 정상 수신

### 시나리오 3: 실패 시 자동 재시도
1. 봇이 60초 내 미시작 시
2. 자동 재시도 1회 → 성공 또는 에러 보고

## 완료 시그니처
- dispatch 후 수동 재전송 없이 봇이 작업을 수신
- 실패 시 자동 재시도 로그 출력
- 기존 정상 동작하는 봇에 회귀 없음

## 레벨
- critical (반복 발생, 작업 수신 실패 = 위임 시스템 신뢰도 저하)

## 프로젝트
- dev-system