# gstack 워크플로우 벤치마킹 적용 — 전체 Phase 한정승인

> 한정승인: 아래 Phase 1~3 전체를 순차적으로 끝까지 진행하세요.
> Phase 간 연결은 파일(산출물 경로)로 합니다.
> ⚠️ 기존 시스템과 충돌 방지 최우선! 기존 기능 깨뜨리지 말 것.

## 참고 자료 (필수 읽기)
- **전체 분석서**: `/home/jay/workspace/memory/research/gstack-workflow-adoption.md`
- **gstack 클론**: `/tmp/gstack/` (MIT 라이선스)
- **기존 분석**: `/home/jay/workspace/memory/research/gstack-deep-analysis.md`

---

## Phase 1 — 즉시 적용 (문서/설정 수정, 충돌 위험 0)

### I-1. 킥오프 강제 질문 6개 추가
**파일**: `/home/jay/workspace/skills/project-kickoff/SKILL.md`
**내용**: gstack `/office-hours`의 6가지 강제 질문을 project-kickoff 스킬에 통합
```
Q1: Demand Reality — 실제 누가 원하는가? (가설이 아닌 증거)
Q2: Status Quo — 현재 workaround은? (없으면 수요 의심)
Q3: Desperate Specificity — 가장 절박한 구체적 인물은?
Q4: Narrowest Wedge — 최소 viable 버전은?
Q5: Observation & Surprise — watch & learn에서 놀라운 발견?
Q6: Future-Fit — 3년 뒤에도 필수인가?
```
- 기존 킥오프 플로우 뒤에 "YC 검증 질문" 섹션으로 추가
- 기존 내용 삭제하지 말 것, 추가만

### I-2. "Boil the Lake" 원칙 추가
**파일**: `/home/jay/workspace/teams/shared/QC-RULES.md`
**내용**: QC 규칙에 "Boil the Lake" 섹션 추가
```
## Boil the Lake 원칙 (gstack ETHOS)
- AI 시대에는 완성 비용이 거의 0. +10% 시간 = -90% quality debt
- Option A(완전, 150 LOC) vs Option B(90%, 80 LOC) → 무조건 A
- Edge case "나중에 처리" 금지 → 즉시 처리
- 테스트 커버리지 100% 목표 (80% 타협 금지)
```
- 기존 QC-RULES 구조 유지, 섹션 추가만

### I-3. 에이전트 미팅 Layer 3 원점추론 추가
**파일**: `/home/jay/workspace/memory/specs/anu-guide.md`
**내용**: 에이전트 미팅 섹션에 다음 추가
```
### Layer 3 원점 추론 (gstack ETHOS: Search Before Building)
- Layer 1: Tried and True (표준 패턴) 확인
- Layer 2: New and Popular (최신 트렌드) 확인
- Layer 3: First Principles — "이 맥락에서 기존 패턴이 틀렸는가?" 질문
- Eureka Moment 발견 시: 명명 + memory/events/eureka-{date}.md에 기록
- 로키(DA)는 "Layer 3 공격" 수행 — 기존 가정을 의도적으로 뒤집기
```
- 기존 미팅 규칙은 유지, 하위에 추가

### I-4. /retro 주간 회고 스킬 생성
**경로**: `/home/jay/workspace/skills/retro/SKILL.md` (신규)
**참고**: gstack `/retro` 스킬 (`/tmp/gstack/retro/SKILL.md.tmpl` 참조)
**내용**: 주간 엔지니어링 회고 스킬
- 최근 1주 git log + task-timers.json 분석
- 배포 연속 기록, 테스트 건강도 트렌드
- Top 3 성장 기회, Top 3 반복 실수
- Eureka Moment 아카이브
- 크로노스(회고분석 센터) 활용 연동
- 산출물: `memory/daily/retro-{date}.md`

---

## Phase 2 — 코드 수정 (기존 시스템 확장)

### A-1. dispatch.py --worktree 옵션
**파일**: `/home/jay/workspace/dispatch.py`
**내용**: git worktree 기반 격리 실행 옵션 추가
- `--worktree` 플래그 추가 (기본값: off, 기존 동작 유지)
- worktree 활성 시:
  1. `git worktree add /tmp/worktree-{task_id} -b task/{task_id}` 실행
  2. 팀 세션의 cwd를 worktree 경로로 설정
  3. 완료 후 merge 또는 PR 생성 옵션
  4. `git worktree remove` 정리
- 참고: gstack의 `bin/dev-setup`, `bin/dev-teardown` 패턴
- 참고: 우리의 기존 `git-worktree-isolation` 스킬 (`/home/jay/workspace/skills/git-worktree-isolation/SKILL.md`)
- ⚠️ 기존 `--worktree` 없이 호출하면 현재와 100% 동일하게 동작해야 함

### A-2. QC 2-pass 감사 추가
**파일**: `/home/jay/workspace/qc_verify.py` (또는 verifiers/ 하위)
**내용**: gstack /review의 2-pass 구조적 감사 패턴 도입
```
Pass 1 — CRITICAL (자동 블록):
  - SQL & Data Safety: 위험한 쿼리 패턴 탐지
  - Race Conditions: 동시 접근 위험 코드 감지
  - LLM Output Trust Boundary: AI 출력 미검증 사용 탐지
  - Enum/Value Completeness: switch/match 불완전 감지

Pass 2 — INFORMATIONAL (경고만):
  - Magic Numbers: 하드코딩 상수
  - Dead Code: 미사용 함수/변수
  - Test Gaps: 테스트 미작성 함수
  - Performance: O(n²) 이상 루프
```
- 새 verifier로 추가 (기존 7개 verifier 수정하지 말 것)
- Pass 1 FAIL = 전체 QC FAIL, Pass 2 = WARN만

### A-3. Health Score verifier
**파일**: `/home/jay/workspace/qc_verify.py` (또는 verifiers/ 하위)
**내용**: 0-100 점수 체계
```
8개 카테고리 × 가중치:
  Console (15%): JS 에러 수
  Links (10%): 깨진 링크 수
  Visual (10%): UI 이슈
  Functional (20%): 기능 버그 (★ 최고 가중치)
  UX (15%): 네비게이션/피드백
  Performance (10%): 로드시간
  Content (5%): 오타/placeholder
  Accessibility (15%): ARIA/키보드
```
- 초기 버전: 코드 기반 정적 분석으로 산출 가능한 항목만 (Console, Functional, Performance)
- 나머지는 NA 또는 수동 입력 필드로 남겨두기
- 보고서에 Health Score 표시

### A-4. 대시보드 Review Readiness 표시
**파일**: `/home/jay/workspace/dashboard/index.html`
**내용**: 프로젝트뷰의 각 task에 진행 단계 배지 표시
```
✓ 위임됨 (dispatch-*.md 존재)
✓ 실행 중 (timer active)
✓ 완료됨 (.done 존재)
✓ QC 통과 (qc_verify PASS)
✗ 미완료 단계
```
- 기존 프로젝트뷰 레이아웃 변경하지 말 것
- task 행의 오른쪽에 작은 배지/아이콘으로 표시
- task-timers.json + events/*.done + reports/ 파일 존재 여부로 판단

---

## Phase 3 — 신규 시스템 구축

### B-1. /ship 자동 배포 스킬
**경로**: `/home/jay/workspace/skills/ship/SKILL.md` (신규)
**참고**: gstack `/ship` 스킬 (`/tmp/gstack/ship/SKILL.md.tmpl` 참조)
**내용**: 원커맨드 배포 워크플로우
- main 브랜치 동기화 (rebase/merge)
- 전체 테스트 실행 + 결과 확인
- 커버리지 감사 (하락 시 경고)
- VERSION bump (semver)
- CHANGELOG 자동 생성 (conventional commits 기반)
- git push + PR 생성 (gh CLI)
- ⚠️ 실제 push/PR은 제이회장님 승인 필요 → 드라이런 모드 기본

### B-2. 크로스모델 코드 리뷰 확장
**파일**: `/home/jay/workspace/dispatch.py` 또는 새 스크립트
**내용**: critical/security 레벨 작업 완료 시 크로스모델 리뷰 자동 트리거
- 비너스(Gemini) 또는 아틀라스(GPT)에 독립 코드 리뷰 요청
- 발견 사항 교차 분석 (Both found / Only A / Only B)
- Agreement rate 보고
- 참고: gstack `/codex` 패턴 (3모드: Review, Challenge, Consult)
- ⚠️ dispatch.py 기존 로직 변경 금지, 새 함수/옵션으로 확장만

### B-3. JSONL 결정 히스토리
**경로**: `/home/jay/workspace/memory/events/decisions/` (신규 디렉토리)
**내용**: 각 작업의 판단 근거를 JSONL로 자동 기록
```json
{"task_id": "task-847.1", "stage": "plan", "decision": "A안 선택", "reason": "성능 우선", "timestamp": "..."}
{"task_id": "task-847.1", "stage": "review", "decision": "Pass 1 PASS", "findings": 0, "timestamp": "..."}
```
- dispatch.py 위임 시 decision 항목 자동 기록
- .done 처리 시 완료 decision 기록
- /retro 스킬에서 decisions/ 디렉토리 참조

---

## 검증 (각 Phase 완료 시)

### Phase 1 검증
- skills/project-kickoff/SKILL.md에 Q1~Q6 포함 확인
- QC-RULES.md에 "Boil the Lake" 섹션 존재 확인
- anu-guide.md에 Layer 3 섹션 존재 확인
- skills/retro/SKILL.md 파일 존재 + 유효성 확인

### Phase 2 검증
- `python3 dispatch.py --help`에 --worktree 옵션 표시
- `python3 dispatch.py --team dev1-team --task "test" --worktree` 드라이런 (실제 위임은 안 함)
- `cd /home/jay/workspace && python3 -m pytest tests/ -x` → 기존 테스트 전체 통과
- `python3 -m pyright dispatch.py qc_verify.py` → 0 errors

### Phase 3 검증
- skills/ship/SKILL.md 존재 + 유효성
- decisions/ 디렉토리 + JSONL 쓰기/읽기 테스트
- 기존 dispatch.py 기능 회귀 테스트

## 주의사항
1. **기존 기능 깨뜨리지 말 것** — 모든 수정은 추가(additive)만, 기존 동작 변경 금지
2. **Phase 순서 준수** — Phase 1 완료 → Phase 2 → Phase 3 순서 (파일 의존성)
3. **각 Phase 완료 시 .done 통보** — 아누가 중간 확인
4. **dashboard/index.html 수정 시 기존 레이아웃 보존** — 새 기능만 추가
5. **dispatch.py 수정 시 기존 테스트 100% 통과 필수**
6. **gstack 코드 참조 시 MIT 라이선스 출처 주석 표기**