아래 앱 SPEC을 5+α 관점에서 검토해줘:

1. 보안: 악용할 수 있는 구멍이 있는가?
2. 수익화: Phase 1.0 의도적 무수익이 정당한가? (게이트 검증 본질)
3. 범위: 혼자 33일 안에 완성 가능한 규모인가?
4. 누락: 없으면 작동 안 되는 필수 기능이 빠졌나?
5. DB: N+1·보안 취약점·확장성 문제가 있는 설계인가?

추가로 (TSV 특수):
- LLM 페르소나 시스템: cache_control 적용 위치 / 환각 방지 표현
- Day 14 가설 검증 게이트: 데이터 수집 + 회고 + 결과 기록 명시 부재 여부
- 외부 API: TheSportsDB / SportsRadar 호출 한도 + 응답 변경
- SEO 키워드: 같은 경기 두 페르소나 글이 SEO 카니발리제이션 위험
- Position C 회색지대: 광고 차단 키워드·콘텐츠 형식 명세 부재 여부

[SPEC.md v1 전체 붙여넣기 — 약 8~10KB]

/model claude-sonnet-4-6
/effort high

SPEC.md를 v2로 패치해줘:

[즉시 반영 4건]
1. §4 [1] cache_control 위치 명시:
   - system prompt + persona-system prompt 끝에 cache_control 명시
   - tool definitions 정의 시 cache_control
   - 캐시 hit 시 약 90% 비용 절감 명시

2. §4 [3] 환각 방지 표현 명시:
   - 시스템 프롬프트에 "제공된 match_facts에 있는 사실만 사용"
   - "추정·예측 X (분석 의견은 OK)"
   - "확실하지 않으면 ~으로 알려졌다 표현"
   - 권1 제7장 CLAUDE.md §5 [7] 본격

3. §4 [3] 자동 일관성 테스트 cron 정지 메커니즘:
   - DB flag 기반 (cron_pause table 단일 행)
   - 다음 cron 실행 시 flag 확인 → 정지 시 skip
   - 운영자 재개: slash command /publish-resume
   - 정지 발생 시 Slack 알림

4. §4 [1] SEO 카니발리제이션 방지:
   - 페르소나별 키워드 분리:
     · STAT: '통계 분석', '데이터로 보는'
     · OBSERVER: '경기 관전 포인트', '한 시각으로'
   - canonical URL: 한 경기당 페르소나별 다른 slug
   - internal link: 한 경기 메인 페이지에서 두 페르소나 글로 link

[PLAN으로 미루는 2건]
5. §4 [2] 끝 박스 — "Day 14 게이트 의식 — PLAN.md 권1 제6장"
6. §7 외부 API 끝 박스 — "호출 한도 fallback — PLAN G2 4주차"

git add SPEC.md
git commit -m "SPEC v2: Gemini 1차 6건 분류 (즉시 4 + PLAN 2)"

## Phase 0 Day 2

[계획]
- Gemini 1차 검토 + SPEC v2 패치 (E3 첫 라운드)

[실행]
- gemini.google.com → SPEC v1 검토 요청
- Gemini 6건 발견 (인프라·LLM edge·SEO·운영 fallback 위주)
- 정직한 분류: 4건 즉시 SPEC v2 + 2건 PLAN.md로 미룸

[LogOnTable 트레이스]
> 결정: 6건 중 4건 즉시 SPEC + 2건 PLAN으로 (줍줍과 동일 비율)
> 근거: 정직한 우선순위. "신뢰 본질 직결" 4건 즉시,
       "운영 단계 / 게이트 의식" 2건 미룸.
> 대안: 6건 모두 즉시 — SPEC 비대해짐 (10KB → 14KB+)
> 부작용: 2건 (Day 14 의식 + API 한도) 은 PLAN G2·권1 제6장에서 다시 등장

[E3 첫 라운드 데이터 입증]
- Gemini 6건 중 5건 인프라·edge case·외부 의존성 (1탄 v2 H-3 패턴)
- 줍줍 사례 (5/6) 와 동일 비율 = 두 도메인 일관 패턴 시작

[누적] Day -1 (0.5h) + Day 1 (1.5h) + Day 2 (2h) = 4h
[E2 페이스] 60h 트리거 56h 여유. 1주차 2일차 안전.

/model claude-sonnet-4-6
/effort high

SPEC.md를 v3로 업데이트해줘:

1. § 회색지대 결정 섹션을 §6 (수익화) 앞에 신설
2. Position C 결정 (4단계 풀 + 5개 차원 매핑)
3. 외부 노출 4자리 미리 점검표 (배포 시 본격은 권3)
4. 다음 장 (권1 제4장 — 두 검토자) 예고:
   "Position C 결정에 대해 또 다른 검토 라운드 받을 예정"

기존 §4·§7 등의 부분 명시는 § 회색지대 결정 섹션과
cross-reference 링크 추가.

git add SPEC.md
git commit -m "SPEC v3: ⚖️ E1 Position C 4단계 본격 (5개 차원·외부 노출 4자리)"

## Phase 0 Day 3

[계획]
- E1 4단계 Position C 결정 본격 + SPEC v3

[실행]
- Position C 단계 ① 영역 식별 (5개 차원)
- 단계 ② 포함 5 / 배제 5
- 단계 ③ 표현 정제 (외부 노출 4자리 일관)
- 단계 ④ SPEC 명시 (변호 논리 + 5개 차원 매핑)
- SPEC v3 통합 + § 회색지대 결정 섹션 신설

[LogOnTable 트레이스]
> 결정: Position C 단일 결정 4단계 풀 적용 → SPEC § 회색지대 결정
> 근거: 1탄 v2 부록 H-1 4단계 매뉴얼 그대로. TSV는 단일 회색지대
       이지만 5개 차원 = 깊은 결정.
> 대안 1: 5개 차원 분리 (5개 결정) — 변호 논리 분산 = 약화
> 대안 2: Position C 명시 X — 6개월 후 단속 위험
> 부작용: 외부 노출 4자리 일관 의무 (권3 본격) + 광고 차단 키워드
       관리 (Phase 1.1)

[★ 두 도메인 E1 비교 패턴]
- 줍줍: 두 결정 (표현 + 개인정보) 형식
- TSV: 단일 결정 (Position C, 5 차원) 형식
- 메타 원칙 (4단계 프레임) 동일
- 도메인 본질 따라 분리·통합 결정의 형식만 다름

[누적] 4h + Day 3 (3h) = 7h
[E2 페이스] 60h 트리거 53h 여유. 1주차 3일차 안전.