Day 22~28: G2 통과 + Phase 1.0 절반 회고

[Claude Code, Sonnet + medium]
"통합 테스트 두 영역 동시 (Agent Teams):

/delegate

  에이전트 A (담당: tests/integration/business-tab.test.ts):
    - 소상공인 탭 통합 테스트 (필터·목록·상세·기여)
    - 닉네임 패턴 검증 (E5 [3] — *수원시 카페 운영하는 든든한 줍줍이*)
    - LLM 분류 결과 노출 (auto_active만)
    - jupjups INSERT → benefits 통계 자동 갱신 검증

  에이전트 B (담당: tests/integration/individual-tab.test.ts):
    - 개인 복지 탭 통합 테스트 (필터·목록·상세·기여)
    - 닉네임 패턴 검증 (시민 톤 — *강남구 취준하는 열정 줍줍이*)
    - target_age·target_household 필터 매칭
    - jupjups INSERT → 트리거 작동

CLAUDE.md §5 Two-Tab Content SSOT 7 규칙 준수 필수.
완료 후 자동 일관성 테스트 (E5 [6]) 실행."

[BUILD.md Day 22 entry]

## Phase 1.0 Day 22

[계획]
- Agent Teams 위임 — 통합 테스트 두 영역 동시

[실행]
- /delegate (에이전트 A·B 병렬)
- tests/integration/business-tab.test.ts (180줄, 18 케이스)
- tests/integration/individual-tab.test.ts (170줄, 16 케이스)
- 일관성 테스트 5/5 통과 (E5 [6])

[LogOnTable 트레이스 — Agent Teams 비용 vs 시간 절감]
> 결정: Agent Teams 위임 채택 (-3.5h 절감)
> 근거: 1탄 v2 새 23장 23-4 절 Day 22 사례 일치. CLAUDE.md §6
       File Structure 폴더 분리가 분배 기준 자연 작동.
> 대안: 순차 9h — E2 페이스 축소 (3h/일) 위반 위험
> 부작용: 토큰 비용 약 2배 ($0.5 → $1) 증가. 시간 절감 가치 > 비용
       (1인 운영자 시간 = 가장 큰 비용)

[누적] 65h + Day 22 (3h) = 68h
[E2] 4주 누적 평균: (35+14+14+3)/4 = 16.5h/주 (안전)

[Claude Code]
"Day 22 통합 테스트 결과 분석:
- 통과: 32/34 케이스
- 실패: 2건 (자세한 원인 + 수정 방안)
- E5 일관성 테스트: 5/5 통과
"

[BUILD.md Day 23 entry]

## Phase 1.0 Day 23

[계획]
- 통합 테스트 실패 2건 분석 + 수정 + 재실행

[실행]
- 실패 2건 수정 (15분 합계)
- 재실행: 34/34 통과 (E5 [6] 5/5 통과 유지)
- src/db/queries.ts 의 null 처리 보강 (3건)

[LogOnTable 트레이스 — null 처리 패턴]
> 결정: 모든 target_* 필터 SQL에 *OR ... IS NULL* 명시
> 근거: SPEC v4 §3-2 *"추정 X, 누락 null"* (E5 [7]) 의 일관 적용
       — DB 쿼리 단계까지 적용
> 대안: target_* null = 'ALL' 가상값 — 코드 분기 ↑
> 부작용: 모든 필터 쿼리에 OR null 추가 → 인덱스 최적화 영향
       (복합 인덱스 0003_indexes.sql는 현재 IS NULL 미고려)
       → Day 25 재검토

[누적] 68h + Day 23 (3h) = 71h

[Claude Code]
"통계 조작 시도 시뮬:

1. 한 사용자가 같은 benefit_id를 두 번 INSERT 시도 → UNIQUE 위반
   확인 + 깔끔한 에러 메시지

2. 한 IP 1시간 내 6번 INSERT 시도 → 6번째에 Redis rate limit 발동
   + 사용자에게 *'잠시 후 재시도'* 노출

3. 다른 카카오 ID 5개로 같은 IP에서 같은 benefit 줍줍 → IP rate
   limit 발동 (R6 보호)

4. 기록: tests/security/manipulation-sim.test.ts"

[BUILD.md Day 24 entry]

## Phase 1.0 Day 24

[계획]
- 통계 조작 시도 시뮬 + UNIQUE/IP rate limit 검증

[실행]
- tests/security/manipulation-sim.test.ts (120줄, 15 시나리오)
- 모든 시나리오 차단 ✅
- DB UNIQUE (1차) + Redis IP (2차) 결합 입증

[LogOnTable 트레이스 — 1차 + 2차 결합의 본질]
> 결정: UNIQUE (DB) + Redis IP (Edge Function) 결합 — 단일 X
> 근거: SPEC v4 §3 + 1탄 v2 새 9장 9-5 절 + 권1 제3장 ⚖️ E1 일관
       *"무엇을 약속하지 않는가"* = "통계 조작 가능성 X" 의 코드 보장
> 대안 1: UNIQUE만 — 다중 카카오 ID 우회 가능 (시나리오 3 차단 X)
> 대안 2: IP rate만 — 한 사용자 두 번 줍줍 가능 (시나리오 1 차단 X)
> 부작용: 두 시스템 의존성 — Redis 장애 시 fallback 명시 필요
       (현재: 'IP rate 통과 허용', 안전 측면)

[E1 회색지대 결정 ① 일관 검증]
"신청 결과를 보장하지 않는다" 의 신뢰 = 통계 신뢰 = 조작 차단.
이번 시뮬이 그 신뢰를 *"가설"* 에서 *"코드 보장"* 으로 전환.

[누적] 71h + Day 24 (3h) = 74h

[Claude Code]
"PLAN.md G2 통과 조건 10개 + 페이스 점검 3개를 모두 점검."

[BUILD.md Day 25 entry]

## Phase 1.0 Day 25

[계획]
- G2 통과 조건 점검 + ★ 페이스 점검 + Day 26·27 준비

[실행]
- 기능 10/10 PASS
- 페이스 3/3 PASS (4주 평균 안전 영역)
- Day 26 토요일 작업 X 의식 명시
- Day 28 G2 의식 준비

[LogOnTable 트레이스 — G2 통과 조건 모두 즉시 PASS의 본질]
> 결정: G2 통과 조건 10개 모두 즉시 PASS (W-C 0건)
> 근거: SPEC v4 + PLAN v2.2 + 권1 75분 패치 + 권2 매일 LogOnTable
       의 누적 효과. *"REVIEW 75분 vs BUILD 50h"* 가 데이터 입증
       — REVIEW에서 W-C 3건이 BUILD 진행 중 자연 PASS 전환.
> 대안: G1·G2가 W-C 다수 발생 — 보강 작업 부담 (실제 발생 X)
> 부작용: 다음 게이트 (G3 Day 42) 도 비슷한 즉시 PASS 패턴 가능.
       그러나 자만 X — G3는 두 탭 UI 자리 (다른 영역).

[누적] 74h + Day 25 (3h) = 77h

[BUILD.md Day 26 entry]

## Phase 1.0 Day 26 — ★ 토요일 작업 X ★

[E2 의식]
- 토요일 작업 X (Day 5·12·19·26 모두 일관)
- 자동 cron 결과만 점검 (5분 수동 작업)

[자동 cron 7일 연속 작동 검증]
✅ daily-fetch-public-data: 매일 03:00 정상 (7일)
✅ daily-deactivate-expired: G-3 트리거 (deadline < NOW() benefits 7건 자동 비활성)
✅ admin-sla-check: SLA 위반 신고 0건 (안정)

[LogOnTable 트레이스 — G-3 운영 검증]
> 결정: G-3 (is_active 트리거) 7일 연속 정상 = 운영 입증
> 근거: 권1 제4장 G-3 발견 → SPEC v4 §3 의도 → PLAN G2 명시 →
       Day 9 함수 + Day 11 cron → Day 19~25 7일 운영 → 작동.
       *"가설 → SPEC 명세 → 코드 → 운영"* 4단계 사이클 완성.
> 대안: cron 실패 시 fallback — 현재 Sentry 미연결 (Day 56 통합 예정)
> 부작용: deadline 경과 benefits 7건 자동 비활성 = 사용자에게
       *"이미 마감된 지원금"* 더 이상 노출 X (정확성 보장)

[누적] 77h (Day 26 변동 없음 — 작업 X)
[다음] Day 27 G2 점검 마무리

[Claude Code]
"G2 최종 점검 — 모든 항목 PASS 확인 + Day 28 의식 준비.

체크:
1. 통합 테스트 34/34 통과 (Day 23 재실행)
2. 통계 조작 시뮬 모두 차단 (Day 24)
3. G2 통과 조건 10/10 (Day 25)
4. 자동 cron 7일 연속 (Day 26)
5. 페이스 점검 3/3 (Day 25)

마지막 검토: REVIEW.md 본문에 G2 통과 1줄 추가"

[BUILD.md Day 27 entry]

## Phase 1.0 Day 27

[계획]
- G2 최종 점검 + REVIEW.md 본문 갱신 + Day 28 의식 준비

[실행]
- G2 모든 항목 PASS 재확인
- REVIEW.md 본문에 G2 통과 entry 추가
- 4주 회고 초안 작성 (Day 28 마무리)
- git status 정리 (모든 변경 commit)

[LogOnTable 트레이스 — REVIEW.md 운영 갱신]
> 결정: REVIEW.md를 *"한 번 만든 후 잠금"* X — 게이트 통과마다 갱신
> 근거: 1탄 v2 새 8장 8-1 절 *"REVIEW.md = 살아있는 문서"* 정신
       일치. G1 통과 (Day 7) + G2 통과 (Day 28) 매번 본문 갱신 의무.
> 대안: REVIEW.md 한 번 만들고 BUILD.md만 갱신 — 6개월 후 검증
       흐름 추적 어려움
> 부작용: REVIEW.md 분량 증가 (5KB → 7KB 추정 권3 끝)

[누적] 77h + Day 27 (3h) = 80h

# G2 통과 의식 — 1탄 v2 새 6장 6-3 (b) 절 적용

# 1. git tag
git tag v0.1-G2-passed
git push origin v0.1-G2-passed

# 2. 4주 회고 작성 (BUILD.md 2KB+)
# 3. Day 29 1일 휴식 의무

git add BUILD.md REVIEW.md
git commit -m "Phase 1.0 Day 28: ★ G2 PASSED + Phase 1.0 절반 회고 + 5확장 운영 사이클 완성 입증"
git push origin v0.1-G2-passed