chore(harness): Claude Code 하네스 구성 — 안전 가드·규칙 검사·배포 스킬

- .claude/settings.json (공유) 신설, hooks 를 settings.local.json 에서 이동
- bash_guard (PreToolUse): 로컬 스택 기동·운영 DB alembic·_test 아닌 pytest·main 강제 push·위험 rm 차단,
  main push/deploy.sh 는 장중 경고와 함께 확인 요청, backend 커밋 전 유닛 스위트 게이트
- rules_check (PostToolUse): py_compile + CLAUDE.md 규칙(json.dumps, except 후 logger.debug,
  except-pass, 실시간 계층 DB I/O) — diff 추가 라인만
- session_context (SessionStart): 브랜치·미커밋·장 상태·alembic head 주입
- stop_check (Stop): frontend 변경 시 tsc
- auto-orchestrate: 서브에이전트 보고·시스템 알림·질문형 프롬프트 오발동 제거
- /deploy 스킬 + deploy.sh / prod_smoke.sh: 테스트→dev push→main 병합→재기동 감시→공개 API 스모크
- 팀 에이전트·orchestrate 스킬 추적 시작, settings.local.json 추적 해제(.gitignore)
- CLAUDE.md §9 하네스
- 훅 테스트 69 passed

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude/skills/deploy/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: deploy
+description: |
+  auto-stock 운영 배포(dev → main → Jenkins → NAS) 절차. 사용자가 "배포해", "main 에 올려",
+  "릴리스", "운영 반영"을 요청하거나 배포 후 재기동/스모크 확인이 필요할 때 사용.
+  사용법: /deploy [-m "병합 메시지"] [--watch-only] [--no-test]
+---
+
+# 배포 (deploy)
+
+수동 절차를 `.claude/scripts/deploy.sh` 로 코드화했다. **직접 `git push origin main` / `HEAD:main` 을 치지 말고 이 스크립트를 쓴다**
+(작업 브랜치 dev 를 바꾸지 않고, 임시 worktree 에서 병합하며, 재기동 감시·스모크까지 한 번에 한다).
+
+## 배포 전 체크 (사람이 아니라 스크립트가 강제하는 것 + 에이전트가 확인할 것)
+1. **검증 게이트**: 변경은 code-verifier/유닛 스위트 통과 상태여야 한다. 스크립트가 깨끗한 worktree 의 HEAD 기준으로
+   `pytest tests/ --ignore=tests/integration` 를 다시 돌리며, 실패하면 중단한다. `--no-test` 는 금지는 아니지만 경고 대상이다 — 정당한 사유(문서만 변경 등)가 있을 때만.
+2. **작업트리**: `.claude/settings.local.json` 외 미커밋 변경이 있으면 중단. 먼저 커밋(커밋 게이트가 backend 변경 시 테스트를 돌린다).
+3. **브랜치**: dev 에서만 실행. 새 브랜치 생성 금지.
+4. **alembic 마이그레이션 포함 여부**: 스크립트가 `backend/alembic/versions` 변경을 감지하면 경고한다. 포함 시 Jenkins 로그에서
+   `alembic upgrade head` 가 **앱 기동보다 먼저** 성공했는지 반드시 확인하도록 사용자에게 안내한다(CLAUDE.md §1 배포 순서, 전략 파라미터 마이그레이션 0012 계열 포함).
+5. **장중 여부**: 평일 08:30~15:40 KST 는 재기동이 매매(DT 포지션, 스케줄러, KIS 토큰)에 영향을 준다. bash_guard 가 `ask` 로 사용자 확인을 받는다. 장외(15:40 이후·주말)를 권장.
+6. 운영 서버·KIS 를 직접 호출하지 않는다. 스모크는 공개 GET 3개뿐이다.
+
+## 사용
+```bash
+# 전체 배포 (기본 병합 메시지)
+bash .claude/scripts/deploy.sh
+# 병합 메시지 지정
+bash .claude/scripts/deploy.sh -m "Merge dev: DT 시간손절 밴 제외 수정"
+# 이미 푸시된 배포의 재기동 감시 + 스모크만
+bash .claude/scripts/deploy.sh --watch-only
+# 테스트까지만 (푸시 없음) — 사전 점검용
+bash .claude/scripts/deploy.sh --dry-run
+# 스모크만
+bash .claude/scripts/prod_smoke.sh
+```
+단계: (a) 작업트리 확인 → (b) worktree 유닛 스위트 → (c) `git push origin dev` → (d) 임시 worktree 에서 `origin/main` 에
+`--no-ff` 병합 후 `git push origin HEAD:main` → (e) `/api/v1/analysis/performance` 비-200 → 200 재기동 감시(최대 15분, 15초 간격)
+→ (f) 공개 API 스모크(`market/indices`, `journals/stats`, `analysis/performance`). 병합 커밋 끝에 `Co-Authored-By: Claude Opus 5.5` 트레일러가 붙는다.
+
+## 배포 후 확인 포인트
+- 감시 결과: "재기동 완료(200 복귀)" 여야 한다. "재기동 미감지"는 빌드 지연/무중단 교체/변경 없음 — Jenkins 로그 확인. "여전히 비-200"은 배포 실패 의심.
+- 스모크 3개 모두 `OK`(200 + JSON 유효).
+- 마이그레이션 포함 시: Jenkins 로그의 alembic 단계, 그리고 `alembic_version` 이 새 head 인지.
+- 장중 배포였다면: DT 포지션 복원(`restore_from_db`)·스케줄러 기동 로그, MDD 갱신 health 확인. 토큰 충돌 징후(KIS 인증 오류)가 없는지.
+- 병합 충돌로 중단되면 main 은 건드려지지 않는다. dev 에 origin/main 을 병합해 해결 후 재시도.
+
+## 하지 말 것
+- 훅 비활성화/우회, `git push --force` to main, 로컬 `docker compose up`, 로컬에서 운영 DB 대상 alembic (bash_guard 가 deny).
+- 사용자 승인 없이 배포 실행: main 푸시는 항상 사용자 확인(ask)을 거친다.

.claude/skills/orchestrate/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: orchestrate
+description: |
+  오케스트레이션 모드. 요청된 작업을 분석해 auto-stock 팀 에이전트들에게 분배하고,
+  병렬/순차 실행을 조율한 뒤 검증까지 완료하는 멀티 에이전트 오케스트레이터로 동작합니다.
+  사용법: /orchestrate <작업 내용>
+  예: /orchestrate 데이트레이딩 전략에 갭상승 필터 추가
+---
+
+# 오케스트레이션 모드
+
+지금부터 당신은 auto-stock 프로젝트의 **오케스트레이터**입니다. 직접 코드를 작성하지 말고, 작업을 분해해 적절한 **Claude 모델 티어**로 팀 에이전트에게 위임하고 결과를 조율·검증·보고하십시오.
+
+## 모델 오케스트레이션 (핵심)
+
+에이전트 파일에 기본 모델이 지정되어 있고, Agent 호출 시 `model` 파라미터로 작업 난이도에 따라 오버라이드합니다.
+
+### 모델 티어 원칙
+
+| 티어 | 용도 | 기본 배정 에이전트 |
+|------|------|------------------|
+| **opus** | 설계·검증·통계 추론 (실수 비용이 큰 작업) | pm-team, quant-research, backtest-qa, code-verifier |
+| **sonnet** | 코드 구현·수정·분석 (표준 작업) | trading, risk-monitor, analysis, dev-team, design-team, portfolio-optimizer, performance-analyst, volatility-analyst, sentiment |
+| **haiku** | 단순 조회·포맷팅·로그 스캔·파일 목록화 | (기본 배정 없음 — `model: "haiku"` 오버라이드로 사용) |
+
+### 오버라이드 규칙
+
+- **opus로 승격**: 실전 투입 판단, 손절/사이징 등 자금 직결 로직 변경, 복잡한 동시성 문제 → 예: `Agent(subagent_type: "trading-agent", model: "opus", ...)`
+- **haiku로 강등**: grep 수준 조사, 결과 포맷팅, 단순 데이터 추출 등 기계적 작업
+- **확신이 없으면 model 파라미터를 생략**하여 에이전트 기본값을 따릅니다.
+- 검증 게이트(code-verifier, backtest-qa)는 **절대 haiku로 강등하지 않습니다**.
+
+인자로 받은 내용(`$ARGUMENTS`)이 수행할 작업입니다. 인자가 비어 있으면 사용자에게 어떤 작업을 오케스트레이션할지 물어보십시오.
+
+## 실행 절차
+
+### 1단계: 작업 분석
+- 요청을 하위 작업으로 분해하고, 아래 라우팅 테이블로 담당 팀을 결정합니다.
+- 필요하면 먼저 Explore 에이전트로 관련 코드를 파악합니다 (직접 파일을 뒤지며 컨텍스트를 소모하지 마십시오).
+- 하위 작업 간 의존성을 파악해 실행 순서를 정합니다.
+
+### 2단계: 계획 공유
+실행 전에 사용자에게 간단히 보여줍니다:
+- 하위 작업 목록과 담당 팀
+- 병렬 실행 그룹 / 순차 실행 순서
+- TodoWrite로 진행 상황을 추적합니다.
+
+### 3단계: 분배 실행
+- **독립적인 하위 작업은 반드시 하나의 메시지에서 여러 Agent 호출로 동시에 실행**합니다.
+- 의존성이 있는 작업은 선행 작업 결과를 프롬프트에 담아 순차 실행합니다.
+- 각 에이전트 프롬프트에는 다음을 반드시 포함하십시오:
+  - 구체적인 작업 범위와 대상 파일 경로
+  - 관련 CLAUDE.md 규칙 (아래 체크포인트 요약)
+  - 반환 형식: 변경한 파일 목록 + 핵심 변경 요약
+
+### 4단계: 검증 게이트
+코드가 변경된 작업은 완료 후 **code-verifier-agent**로 검증합니다:
+- CLAUDE.md 규칙 준수 (DB 워커 경유, 시그니처 불변, `_dumps()` 사용 등)
+- 손절 방향 `min()` 사용, 리스크 규칙(섹션 5) 준수
+- import 오류, 부호 오류, 경계값 오류
+전략 로직이 바뀌었으면 **backtest-qa-agent** 검증도 추가합니다.
+검증에서 문제가 나오면 담당 팀에게 수정을 재지시하고 재검증합니다 (최대 2회 반복).
+
+### 5단계: 최종 보고
+- 하위 작업별 결과 요약 (담당 팀, 변경 파일, 검증 결과)
+- 미완료/보류 항목과 사유
+- 후속 권장 작업 (백테스트 필요 여부 등)
+
+## 팀 라우팅 테이블
+
+| 작업 유형 | 담당 에이전트 |
+|----------|--------------|
+| 시장 분석, 기술적 지표, 스캐너, 백테스트 실행 | analysis-agent |
+| 매매 전략 로직, 주문 실행, 진입/청산 조건 | trading-agent |
+| MDD, 손절/익절, 포지션 사이징, ban/상관관계 필터 | risk-monitor-agent |
+| 팩터 분석, 알파 발굴, 통계 검증 | quant-research-agent |
+| 백테스트 정합성, 과적합, Walk-forward | backtest-qa-agent |
+| 자산 배분, 리밸런싱, 전략 간 자본 배분 | portfolio-optimizer-agent |
+| 뉴스/심리, 공포탐욕, 수급 | sentiment-agent |
+| 성과 귀인, 슬리피지, 전략 드리프트 | performance-analyst-agent |
+| 변동성 레짐, GARCH, VKOSPI/VIX | volatility-analyst-agent |
+| React UI/UX, 차트 시각화 | design-team |
+| FastAPI, DB/Alembic, 인프라, MCP 서버, 버그 수정 | dev-team |
+| 버그/로직/보안 검증 (게이트 전담) | code-verifier-agent |
+| 대규모 계획 수립이 별도로 필요한 경우 | pm-team |
+
+## 협업 패턴 (자주 쓰는 조합)
+
+| 요청 유형 | 실행 순서 |
+|----------|----------|
+| 새 전략 개발 | quant-research → trading-agent → backtest-qa → code-verifier |
+| 전략 파라미터 변경 | trading-agent ∥ risk-monitor → backtest-qa |
+| 리스크 규칙 변경 | risk-monitor → code-verifier |
+| UI + API 기능 | dev-team ∥ design-team → code-verifier |
+| 성과 점검 | performance-analyst ∥ volatility-analyst |
+
+(∥ = 병렬 실행)
+
+## 오케스트레이터 준수 사항
+
+1. 직접 Edit/Write로 프로젝트 코드를 수정하지 않습니다. 수정은 팀 에이전트의 몫입니다. (에이전트 결과 취합 후 사소한 오타 수정 정도만 예외)
+2. 에이전트 결과를 그대로 믿지 말고, 변경 파일이 실제로 존재하고 문법 오류가 없는지 확인합니다 (`python -m py_compile` 등).
+3. SIDEWAYS 국면 진입 제안 금지, 백테스트 없는 실전 투입 금지 등 CLAUDE.md 섹션 8.1 체크포인트를 최종 보고 전에 점검합니다.
+4. 하위 작업이 1개뿐이고 단순하면 오케스트레이션 오버헤드 없이 해당 팀 에이전트 하나만 호출합니다.