diff --git a/members/yenachang924/idea.md b/members/yenachang924/idea.md
index 16c2345..a4d1614 100644
--- a/members/yenachang924/idea.md
+++ b/members/yenachang924/idea.md
@@ -1,14 +1,14 @@
-# 💡 프로젝트 기획서 — 빵킵 (BbangKeep)
+# 💡 프로젝트 기획서. 빵킵 (BbangKeep)
 
 | 항목 | 내용 |
 | --- | --- |
 | **1. 한 줄 정의** | 품절 전에 원하는 빵을 확보하고 싶은 빵지순례 소비자와, 생산량을 감으로 정하는 동네 빵집 사장을 위한 **선결제 픽업 예약 서비스**. |
-| **2. 문제** | 당일 제조·당일 소진이라 손님은 "가면 그 빵이 있는지"를 알 수 없다 → 오픈런으로 시간을 쓰거나, 헛걸음하거나, 원치 않는 차선을 산다. 사장은 품절 문의 응대에 시달리고 품절 후 방문객은 전부 놓친 매출. 지금 이 둘을 잇는 채널은 인스타 스토리(일방향·예약 불가·24시간 소멸)와 전화뿐. |
-| **3. 해결책** | 사장은 아침 1회 5분, 오늘의 굽는 시간표와 시간대별 수량만 올린다. 손님은 시간대를 골라 정가 선결제로 '킵'하고 줄 없이 픽업. 핵심은 일부러 **하지 않는 두 가지** — 실시간 재고 입력 요구 없음(사장이 지속 가능해야 하니까), 할인 없음(파는 것은 싼 빵이 아니라 "가면 반드시 있다"는 확실함). |
-| **4. 왜 지금** | 수요 쪽: 빵지순례가 대중 취미가 되며 '빵케팅' 신조어까지 생겼는데, 확보 수단만 공백으로 남아 있다. 기술 쪽: AI 코딩 도구로 개발 파트너 없이도 6주 안에 예약 흐름을 붙일 수 있게 됐다 — 작년이라면 기획서에서 멈췄을 규모. (가설) 장기적으로는 쌓인 킵 데이터 위에 LLM을 얹어 "내일 몇 개 구울까"를 제안하는 운영 비서로 확장 가능하나, 데이터 없는 AI 도입은 하지 않는다(순서: 거래 → 데이터 → 자동화). |
-| **5. 사용자** | 1차 사용자는 서울 망원·연남의 중위권 인기 빵집 — 인스타에 품절 공지는 올리지만 예약·웨이팅 앱은 쓰지 않는 곳. 접촉 대상 30곳 리스트업. 2차는 그 가게를 따라다니는 빵지순례형 소비자. (가설) 전국에서 품절이 발생하는 인기 로컬 빵집 약 900곳 — 전체 1.85만 곳의 5% 추산. |
-| **6. 대안·경쟁** | 럭키밀(마감·랜덤박스·할인), 캐치테이블·테이블링(도착한 손님의 줄 관리), 해피오더(프랜차이즈 자체 앱), 인스타 DM(현재 관행). 차별점 한 문장: **"럭키밀이 마감의 랜덤을 판다면, 빵킵은 오픈의 지명을 판다"** — 아침·지명·정가. 웨이팅이 줄을 관리한다면 빵킵은 도착하기 전에 확보한다. |
-| **7. 제품** | 핵심 기능 — ① 사장의 아침 입력을 예약 페이지로 변환 ② 손님의 시간대 선택·**선결제 킵** ③ 품절/마감 원터치. **6주 MVP는 2단계**: (1단계) 내가 콘시어지 운영에 쓸 도구 — 카톡으로 받은 한 줄을 예약 페이지로 만들고 들어온 예약을 가게별로 집계 (2단계) 손님용 예약+결제 페이지. **결제는 샌드박스/테스트 연동**으로 결제창 호출→콜백→성공·실패 분기까지 흐름을 붙여 학습하되, 실 정산 구조는 사업계획서대로 손님→가게 계좌 직접 입금을 유지한다(빵킵은 돈을 만지지 않음). **범위 밖**: 실시간 재고, 실 PG 계약·정산, 네이티브 앱, 회원가입/로그인. |
-| **8. 지속 방법** | 할인 없이 '확보의 값'을 받되, 각 과금은 앞 단계 지표가 증명된 뒤에만 켠다. Phase 0 수수료 0원(이 시기의 수익은 거래 데이터와 사장 신뢰) → Phase 1 소비자 킵 수수료 건당 500원 → Phase 2 가게 거래 수수료 5%(배달앱의 절반) → Phase 3 구독·수요예측 데이터. (가설) 모든 수치는 가정 기반 추산이며, 킵 전환율 5% 미만이면 '오늘의 빵 알림'으로 피벗. |
-| **9. 나(팀)** | 타깃 당사자 — 빵케팅을 직접 겪는 헤비유저라 문제를 몸으로 안다. 캠퍼스 상권 플랫폼 PM으로 소상공인·소비자 양면 시장을 설계해봤다. 22개 출처 교차검증 조사와 반증 가설 중심 검증 설계를 직접 수행 — 아이디어에 취하지 않고 죽여보는 훈련이 돼 있다. 부족한 건 개발 경험이고, 이 6주가 그 보완 과정이다. |
-| **10. 6주 계획** | **3주차** 데이터 모델·화면 설계 + 사장 입력 → 예약 페이지 생성 흐름 1개 완성(가상 빵집 1곳) · **4주차** 예약 접수·집계 붙여서 콘시어지 도구 한 바퀴 돌리기 · **5주차** 손님용 예약 페이지(시간대 선택 → 예약 확정) + **결제 샌드박스 연동**(결제창 → 콜백 → 성공·실패 분기) · **6주차** 배포 + 가상 데이터 시나리오 테스트 + 발표 |
+| **2. 문제** | 당일 제조, 당일 소진이라 손님은 "가면 그 빵이 있는지"를 알 수 없다 → 오픈런으로 시간을 쓰거나, 헛걸음하거나, 원치 않는 차선을 산다. 사장은 품절 문의 응대에 시달리고 품절 후 방문객은 전부 놓친 매출. 지금 이 둘을 잇는 채널은 인스타 스토리(일방향, 예약 불가, 24시간 소멸)와 전화뿐. |
+| **3. 해결책** | 사장은 아침 1회 5분, 오늘의 굽는 시간표와 시간대별 수량만 올린다. 손님은 시간대를 골라 정가 선결제로 '킵'하고 줄 없이 픽업. 핵심은 일부러 **하지 않는 두 가지**. 실시간 재고 입력 요구 없음(사장이 지속 가능해야 하니까), 할인 없음(파는 것은 싼 빵이 아니라 "가면 반드시 있다"는 확실함). |
+| **4. 왜 지금** | 수요 쪽: 빵지순례가 대중 취미가 되며 '빵케팅' 신조어까지 생겼는데, 확보 수단만 공백으로 남아 있다. 기술 쪽: AI 코딩 도구로 개발 파트너 없이도 6주 안에 예약 흐름을 붙일 수 있게 됐다. 작년이라면 기획서에서 멈췄을 규모. (가설) 장기적으로는 쌓인 킵 데이터 위에 LLM을 얹어 "내일 몇 개 구울까"를 제안하는 운영 비서로 확장 가능하나, 데이터 없는 AI 도입은 하지 않는다(순서: 거래 → 데이터 → 자동화). |
+| **5. 사용자** | 1차 사용자는 서울 망원, 연남의 중위권 인기 빵집. 인스타에 품절 공지는 올리지만 예약, 웨이팅 앱은 쓰지 않는 곳. 접촉 대상 30곳 리스트업. 2차는 그 가게를 따라다니는 빵지순례형 소비자. (가설) 전국에서 품절이 발생하는 인기 로컬 빵집 약 900곳. 전체 1.85만 곳의 5% 추산. |
+| **6. 대안, 경쟁** | 럭키밀(마감, 랜덤박스, 할인), 캐치테이블, 테이블링(도착한 손님의 줄 관리), 해피오더(프랜차이즈 자체 앱), 인스타 DM(현재 관행). 차별점 한 문장: **"럭키밀이 마감의 랜덤을 판다면, 빵킵은 오픈의 지명을 판다"**. 아침, 지명, 정가. 웨이팅이 줄을 관리한다면 빵킵은 도착하기 전에 확보한다. |
+| **7. 제품** | 핵심 기능. ① 사장의 아침 입력을 예약 페이지로 변환 ② 손님의 시간대 선택, **선결제 킵** ③ 품절/마감 원터치. **6주 MVP는 2단계**: (1단계) 내가 콘시어지 운영에 쓸 도구. 카톡으로 받은 한 줄을 예약 페이지로 만들고 들어온 예약을 가게별로 집계 (2단계) 손님용 예약+결제 페이지. **결제는 샌드박스/테스트 연동**으로 결제창 호출→콜백→성공, 실패 분기까지 흐름을 붙여 학습하되, 실 정산 구조는 사업계획서대로 손님→가게 계좌 직접 입금을 유지한다(빵킵은 돈을 만지지 않음). **범위 밖**: 실시간 재고, 실 PG 계약, 정산, 네이티브 앱, 회원가입/로그인. |
+| **8. 지속 방법** | 할인 없이 '확보의 값'을 받되, 각 과금은 앞 단계 지표가 증명된 뒤에만 켠다. Phase 0 수수료 0원(이 시기의 수익은 거래 데이터와 사장 신뢰) → Phase 1 소비자 킵 수수료 건당 500원 → Phase 2 가게 거래 수수료 5%(배달앱의 절반) → Phase 3 구독, 수요예측 데이터. (가설) 모든 수치는 가정 기반 추산이며, 킵 전환율 5% 미만이면 '오늘의 빵 알림'으로 피벗. |
+| **9. 나(팀)** | 타깃 당사자. 빵케팅을 직접 겪는 헤비유저라 문제를 몸으로 안다. 캠퍼스 상권 플랫폼 PM으로 소상공인, 소비자 양면 시장을 설계해봤다. 22개 출처 교차검증 조사와 반증 가설 중심 검증 설계를 직접 수행. 아이디어에 취하지 않고 죽여보는 훈련이 돼 있다. 부족한 건 개발 경험이고, 이 6주가 그 보완 과정이다. |
+| **10. 6주 계획** | **3주차** 데이터 모델, 화면 설계 + 사장 입력 → 예약 페이지 생성 흐름 1개 완성(가상 빵집 1곳), **4주차** 예약 접수, 집계 붙여서 콘시어지 도구 한 바퀴 돌리기, **5주차** 손님용 예약 페이지(시간대 선택 → 예약 확정) + **결제 샌드박스 연동**(결제창 → 콜백 → 성공, 실패 분기), **6주차** 배포 + 가상 데이터 시나리오 테스트 + 발표 |
diff --git a/members/yenachang924/project.md b/members/yenachang924/project.md
new file mode 100644
index 0000000..25a9090
--- /dev/null
+++ b/members/yenachang924/project.md
@@ -0,0 +1,22 @@
+# 빵킵 (BbangKeep)
+
+동네 빵집의 오늘 굽는 양을 선결제 픽업 예약으로 바꾸는 서비스.
+사장님은 아침에 한 줄("내일 소금빵 11시 40개, 앙버터 쉬어감")을 적고, 손님은 시간대를 골라 정가로 미리 결제하고 줄 없이 픽업합니다.
+
+- 서비스: https://bbangkeep.vercel.app (데모 계정 `owner@salt.com`, `test@test.com`, 비밀번호 `Test1234!`)
+- 레포: https://github.com/yenachang924/bbangkeep
+- 스택: Next.js 16, Prisma 6, Postgres(Render), Vercel. Spring Boot(Kotlin)로 결제와 재고를 이식하는 중
+
+## 만든 것
+
+- 사장님 AI 비서: 한 줄 문장을 초안 카드로 바꾸고, 사장님이 승인해야 발행. LLM은 게이트웨이 뒤(기본은 룰 파서, 키가 있으면 OpenAI)
+- 재고와 결제: 조건부 원자 UPDATE로 재고 차감, 금액은 서버가 정함, 승인은 멱등, PG는 인터페이스 뒤(모의 PG로 시연)
+- 운영: CI(테스트, 빌드, 브라우저 E2E, API 계약), keepalive, 주간 백업, 픽업 리마인더
+- 문서: ADR 11건, 측정 결과(proof), 인수인계(HANDOFF), OpenAPI 계약
+
+## Claude Code를 어떻게 썼나
+
+- 규약은 AGENTS.md에, 결정은 ADR에, 숫자는 proof에. 에이전트가 읽고 지킬 수 있는 문장으로
+- 마지막 주는 HANDOFF 한 장과 프롬프트로 새 세션을 시작해 PR 단위로 받고, 내가 읽고 머지
+- 스키마 변경, 운영 DB, 시크릿은 승인 없이는 못 건드리게 금지 목록을 먼저 줌
+- MCP 서버로 Claude가 사장님 비서 도구(시간표 조회, 초안, 발행)를 쓰게 함
diff --git a/members/yenachang924/retrospective.md b/members/yenachang924/retrospective.md
new file mode 100644
index 0000000..c8882dd
--- /dev/null
+++ b/members/yenachang924/retrospective.md
@@ -0,0 +1,26 @@
+# 빵킵 6주 회고
+
+## 무엇을 만들었나
+동네 빵집의 오늘 굽는 양을 예약으로 바꾸는 선결제 픽업 서비스. 사장님은 아침 한 줄, 손님은 시간대 선택과 결제.
+https://bbangkeep.vercel.app / https://github.com/yenachang924/bbangkeep
+
+## 워크플로우가 바뀐 것
+1. 1주: 내 코드를 Claude에게 채점시켰다. 발견은 Claude, 결정은 나.
+2. 2주: 규칙은 커밋되어야 존재한다. 문서는 해석되지만 훅은 실행된다.
+3. 4주: 맨땅 대신 비슷한 서비스를 먼저 읽었다. 가져올 것, 버릴 것, 달라야 할 것을 적고 설계.
+4. 매주: 결정은 ADR, 수치는 proof. 막힌 곳도 "알려진 구멍"으로 적어두고 넘어갔다.
+5. 6주: HANDOFF 한 장으로 새 세션이 기능을 이어 만들었다. 내 역할은 무엇, 왜, 어디까지.
+
+## 배운 것
+- 제약이 구조를 만들었다. PG가 없어서 PaymentGateway, 키가 없어서 LlmGateway, 채널이 없어서 NotificationGateway. 같은 모양을 세 번 쓰니 내 것이 됐다.
+- AI는 발행하지 않는다. 초안을 쓰고 사람이 승인한다. 결제에서 클라이언트를 믿지 않는 태도를 LLM에도 똑같이 적용했다.
+- 에이전트에게 "하지 말 것"을 먼저 주면 나머지는 빨라도 안전하다.
+- 측정하면 보인다. 느리다고 느낀 것이 콜드스타트가 아니라 리전 거리였다.
+
+## 아쉬운 것
+- 사용자가 아직 없다. 코드보다 노출이 늦었다.
+- 실결제와 알림톡은 키와 사업자등록 뒤에 있다.
+- 빠르게 들어온 코드를 다 읽지 못한 구간이 있다. 그래서 Spring의 approve, cancel은 내 손으로 남겨뒀다.
+
+## 다음
+써 줄 가게 한 곳 찾기. Spring approve, cancel 직접 구현해서 같은 계약 테스트 통과시키기.
diff --git a/members/yenachang924/week01.md b/members/yenachang924/week01.md
index e445b8c..0db85de 100644
--- a/members/yenachang924/week01.md
+++ b/members/yenachang924/week01.md
@@ -15,11 +15,11 @@ git도 서툴고 Claude Code도 터미널에 깐 지 얼마 안 된 상태라, 
 
 ## 1. 환경 세팅 체크리스트
 
-- [x] 설치 & 로그인 — `claude --version` → 2.1.215 확인
-- [x] VS Code 연동 — 확장 설치, 터미널을 프로젝트 폴더에서 여는 것부터 배움
-- [x] `CLAUDE.md` 생성 — `/init` 실행 (→ 아래 6번)
-- [x] 첫 대화 & 첫 수정 — 프로젝트 설명 받고 diff 수락까지 (→ 아래 3·5번)
-- [x] git 커밋 위임 — 커밋·push·PR 브랜치 준비까지 맡겨봄 (→ 아래 5·7번)
+- [x] 설치 & 로그인. `claude --version` → 2.1.215 확인
+- [x] VS Code 연동. 확장 설치, 터미널을 프로젝트 폴더에서 여는 것부터 배움
+- [x] `CLAUDE.md` 생성. `/init` 실행 (→ 아래 6번)
+- [x] 첫 대화 & 첫 수정. 프로젝트 설명 받고 diff 수락까지 (→ 아래 3, 5번)
+- [x] git 커밋 위임. 커밋, push, PR 브랜치 준비까지 맡겨봄 (→ 아래 5, 7번)
 
 ## 2. 공식 문서 읽기
 
@@ -65,7 +65,7 @@ git log --oneline -- index.html             → 커밋 다수
 커밋을 맡겼더니 예상 밖의 장면이 이어졌다.
 
 - 커밋 전에 스테이징 상태부터 확인하고, **딱 그 한 줄만** 커밋했다
-- git identity가 설정 안 된 걸 발견하자, 기존 커밋의 author를 조회해 **같은 주소로, 이 저장소에만**(`git config --local`) 설정했다 — 전역 설정은 안 건드렸다
+- git identity가 설정 안 된 걸 발견하자, 기존 커밋의 author를 조회해 **같은 주소로, 이 저장소에만**(`git config --local`) 설정했다. 전역 설정은 안 건드렸다
 - 커밋 메시지에 문자를 잘못 섞은 걸(`@` 혼입) **스스로 발견하고**, "아직 push 전이라 안전하다"는 판단과 함께 `--amend`로 고쳤다
 - push는 자기 판단으로 하지 않고 "원격 반영이 필요하면 말씀해 주세요"에서 멈췄다
 
@@ -78,9 +78,9 @@ Claude도 실수를 한다. 다만 실수를 스스로 감지했고, 고쳐도 
 
 `/init`을 돌리자 CLAUDE.md 작업을 **worktree로 격리**해서 진행했다(내 작업 폴더를 건드리지 않고 딴 방에서 작업). 결과물에서 눈에 띈 것 세 가지.
 
-1. **버그 '사례'가 아니라 '유형'을 문서화했다.** 작업 브랜치 기준에는 GET / 버그가 아직 남아 있었는데, 그걸 알아채고 `GET /` 설명을 특정 파일명에 의존하지 않는 서술로 고쳐 썼다 — "하드코딩된 파일명이 실제 커밋된 페이지와 다르면 루트만 조용히 죽고 API는 다 살아 있어서 놓치기 쉽다"는 식으로.
+1. **버그 '사례'가 아니라 '유형'을 문서화했다.** 작업 브랜치 기준에는 GET / 버그가 아직 남아 있었는데, 그걸 알아채고 `GET /` 설명을 특정 파일명에 의존하지 않는 서술로 고쳐 썼다. "하드코딩된 파일명이 실제 커밋된 페이지와 다르면 루트만 조용히 죽고 API는 다 살아 있어서 놓치기 쉽다"는 식으로.
 2. **주장을 코드 라인과 대조했다고 명시했다.** GREATEST 병합, 5클릭 동기화, 커넥션 풀 설정 같은 기술 서술 전부를 실제 코드와 대조 검증했다고 밝혔다.
-3. **내가 모르던 위험을 문서에 남겼다** — "`index.html`을 로컬에서 열어도 프로덕션 DB를 읽고 쓴다. 쓰기 테스트 전에 API 주소를 localhost로 바꿔라."
+3. **내가 모르던 위험을 문서에 남겼다**. "`index.html`을 로컬에서 열어도 프로덕션 DB를 읽고 쓴다. 쓰기 테스트 전에 API 주소를 localhost로 바꿔라."
 
 첫 대화 요약이 "지금 이 레포의 상태와 문제"를 말한다면, CLAUDE.md는 "다음 세션의 Claude가 헛짚지 않게 하는 지도"에 가까웠다. 같은 레포를 읽고도 산출물의 목적이 달랐다.
 
@@ -110,5 +110,5 @@ Claude도 실수를 한다. 다만 실수를 스스로 감지했고, 고쳐도 
 
 - [ ] `.DS_Store` 제거 + `.gitignore` 추가 커밋
 - [ ] GitHub About의 "SQLite"를 실제(PostgreSQL)에 맞게 수정
-- [ ] 보안 구멍(`/dashboard` 무인증)은 2주차에 권한·훅을 배우면서 처리 예정
-- [ ] 가설 실험: "배포 의도를 CLAUDE.md에 적어두면 Claude의 수정 제안이 달라질까" — A/B로 확인해보고 싶다
+- [ ] 보안 구멍(`/dashboard` 무인증)은 2주차에 권한, 훅을 배우면서 처리 예정
+- [ ] 가설 실험: "배포 의도를 CLAUDE.md에 적어두면 Claude의 수정 제안이 달라질까". A/B로 확인해보고 싶다
diff --git a/members/yenachang924/week02.md b/members/yenachang924/week02.md
index bdac375..2fee29a 100644
--- a/members/yenachang924/week02.md
+++ b/members/yenachang924/week02.md
@@ -7,17 +7,17 @@
 
 ## 1. 워크플로우 1바퀴 (필수)
 
-**작업한 것 (버그 수정 + 보안 수정):** 프로덕션 `/ranking` 500 장애 대응, 그리고 그 복구 과정에 얹은 분석·운영 엔드포인트 인증 하드닝(fail-closed).
+**작업한 것 (버그 수정 + 보안 수정):** 프로덕션 `/ranking` 500 장애 대응, 그리고 그 복구 과정에 얹은 분석, 운영 엔드포인트 인증 하드닝(fail-closed).
 
 **과정: 탐색 → 계획 → 구현 → 검증 → 커밋 → PR**
 
-- **탐색** — 프로덕션 `/ranking`이 500. 가설을 두 개 세웠다. ①Render 무료 티어 콜드스타트 ②1주차에 발견해둔 "무료 Postgres 30일 만료". 서버가 완전히 기동한 뒤에도 500이 유지되어 ①을 기각했다. 결정적 증거는 프로덕션 로그의 `failed to resolve host` — Render 내부망에서조차 호스트가 사라졌다는 뜻이라 DB 인스턴스 자체의 소멸을 가리켰다. 마지막으로 만료 확정 메일까지 확인해 3중으로 닫았다.
+- **탐색**. 프로덕션 `/ranking`이 500. 가설을 두 개 세웠다. ①Render 무료 티어 콜드스타트 ②1주차에 발견해둔 "무료 Postgres 30일 만료". 서버가 완전히 기동한 뒤에도 500이 유지되어 ①을 기각했다. 결정적 증거는 프로덕션 로그의 `failed to resolve host`: Render 내부망에서조차 호스트가 사라졌다는 뜻이라 DB 인스턴스 자체의 소멸을 가리켰다. 마지막으로 만료 확정 메일까지 확인해 3중으로 닫았다.
   → **1주차에 "위험하다"고 적어둔 항목이 2주차에 실제로 터졌다.** 경고 메일은 6/11, 6/25 두 번 왔지만 놓쳤고, 14일 유예기간도 지나 있었다.
-- **계획** — 복구 옵션 중 "무료 DB 빠른 재생성"을 선택했다. 30일 만료 구조가 그대로 유지된다는 걸 알면서 내린 결정이라, 대신 만료 대비 규칙을 문서에 남기기로 했다. 같은 사이클에 1주차에 발견해둔 `/dashboard` 무인증 구멍도 함께 막기로 했다.
-- **구현** — 분석·운영 엔드포인트에 HTTP Basic 인증. 비밀번호 환경변수가 없으면 통과가 아니라 **차단**되도록 fail-closed로 설계했다.
-- **검증** — 새로 만든 빈 DB로 계획서 8단계를 전부 통과시켰다. 특히 `init_db`의 맨땅 생성과 멱등성은 **이전까지 한 번도 실전 검증된 적이 없던 경로**였다. 그 외 쓰기 단조 불변식, 인증 401/200/503, 브라우저 실렌더까지 확인.
-  로컬 Claude가 도구 제약(Chrome이 URL 자격증명·`file://` 거부, curl 셸 인용 깨짐)에 부딪힐 때마다 우회하면서도 "바이트 동일" 확인 같은 방식으로 검증의 의미를 보존한 게 인상적이었다.
-- **커밋 → PR** — 여기서 사건이 하나 터졌는데, 그건 3번 섹션에서 이어 쓴다.
+- **계획**. 복구 옵션 중 "무료 DB 빠른 재생성"을 선택했다. 30일 만료 구조가 그대로 유지된다는 걸 알면서 내린 결정이라, 대신 만료 대비 규칙을 문서에 남기기로 했다. 같은 사이클에 1주차에 발견해둔 `/dashboard` 무인증 구멍도 함께 막기로 했다.
+- **구현**. 분석, 운영 엔드포인트에 HTTP Basic 인증. 비밀번호 환경변수가 없으면 통과가 아니라 **차단**되도록 fail-closed로 설계했다.
+- **검증**. 새로 만든 빈 DB로 계획서 8단계를 전부 통과시켰다. 특히 `init_db`의 맨땅 생성과 멱등성은 **이전까지 한 번도 실전 검증된 적이 없던 경로**였다. 그 외 쓰기 단조 불변식, 인증 401/200/503, 브라우저 실렌더까지 확인.
+  로컬 Claude가 도구 제약(Chrome이 URL 자격증명, `file://` 거부, curl 셸 인용 깨짐)에 부딪힐 때마다 우회하면서도 "바이트 동일" 확인 같은 방식으로 검증의 의미를 보존한 게 인상적이었다.
+- **커밋 → PR**. 여기서 사건이 하나 터졌는데, 그건 3번 섹션에서 이어 쓴다.
 
 **커밋 / PR 링크:**
 - 인증 하드닝: `71aac5c` → PR #5 (링크: https://github.com/yenachang924/popketmon-server/pull/5)
@@ -33,7 +33,7 @@
 
 **`/init` 후 직접 손본 내용:** `/init`이 만들어준 구조 설명 위에, 이 프로젝트의 **"운영 의도"**(무엇을 지키려고 하는 서비스인지)를 얹었다. 그리고 커밋 컨벤션("main 직접 커밋 금지, 브랜치+PR")과 이번 주에 추가한 pg_dump 백업 규칙.
 
-**before/after — Claude의 답이 어떻게 달라졌나:**
+**before/after. Claude의 답이 어떻게 달라졌나:**
 같은 보안 수정 요청을 운영 의도 주입 전/후로 각각 던져 A/B로 비교했다. 결과는 예상과 달랐다.
 
 - **제안된 FIX 자체는 바뀌지 않았다.** 고칠 대상도, 방법도 같았다.
@@ -41,9 +41,9 @@
 - → 발견: **의도는 "무엇을 고칠지"보다 "왜 고치는지 설명하는 방식"에 먼저 반영된다.**
 - (정직하게: after 쪽에서 `/stats` 관련 추가 발견이 하나 더 나왔는데, 이건 주입 효과인지 실행 편차인지 분리할 수 없어 confound로 남겨둔다.)
 
-**그리고 반전 — 규칙은 커밋된 적이 없었다.**
+**그리고 반전. 규칙은 커밋된 적이 없었다.**
 내가 분명히 넣었다고 기억하는 "항상 새 브랜치" 규칙이 CLAUDE.md에 없었다. 한글로 grep했더니 아무것도 안 나왔는데, 인코딩 문제였을 수 있어서 영어 `main`으로 다시 grep해 음성 결과를 재검증했다. 그래도 없었다.
-로컬 Claude에게 전수 추적(`-S`, 전 ref, stash, reflog, worktree)을 시켰고 결론은 이랬다 — **그 규칙은 git에 커밋된 적 자체가 없다. 작업 트리에만 있다가 유실됐고, 시점과 원인은 git으로 특정 불가능하다.**
+로컬 Claude에게 전수 추적(`-S`, 전 ref, stash, reflog, worktree)을 시켰고 결론은 이랬다. **그 규칙은 git에 커밋된 적 자체가 없다. 작업 트리에만 있다가 유실됐고, 시점과 원인은 git으로 특정 불가능하다.**
 → 그래서 이번 주 결론 문장: **"규칙은 커밋되어야 존재한다."**
 
 ---
@@ -63,29 +63,29 @@
 **결론: 문서에 적힌 규칙은 advisory다. 강제하려면 실행 레이어가 필요하다.** 그래서 훅을 만들었다.
 
 **만든 커맨드 (`.claude/commands/commit.md`):**
-이미 존재하던 커맨드라 새로 만들기 전에 내용부터 확인했다. frontmatter의 `allowed-tools: Bash(git:*)`로 도구를 제한하고, 본문에서 `` !`git status` ``·`` !`git diff --staged` `` 문법으로 셸 출력을 컨텍스트에 넣은 뒤 Conventional Commits 형식으로 커밋시키는 헬퍼였다.
+이미 존재하던 커맨드라 새로 만들기 전에 내용부터 확인했다. frontmatter의 `allowed-tools: Bash(git:*)`로 도구를 제한하고, 본문에서 `` !`git status` ``, `` !`git diff --staged` `` 문법으로 셸 출력을 컨텍스트에 넣은 뒤 Conventional Commits 형식으로 커밋시키는 헬퍼였다.
 **문제: 브랜치 얘기가 한 줄도 없었다.** main에서 `/commit`을 치면 그대로 main에 커밋된다. 그래서 "커밋 전 브랜치 확인, main이면 커밋하지 말고 브랜치 생성을 먼저 제안" 지시를 추가했다.
 
 **만든 Hook (`.claude/hooks/block_main_commit.py` + `.claude/settings.json`):**
-`PreToolUse` 이벤트, matcher는 `Bash`. stdin으로 들어온 훅 페이로드에서 실행될 명령을 꺼내, **실제 `git commit` 실행인지** 판별한다. 문자열에 "commit"이 들어있는지로 보지 않고 `&&`·`||`·`;`·`|` 등 셸 연산자로 명령을 세그먼트 단위로 잘라 판별했다(우회 방지). main이면 exit 2 + 한국어 stderr로 차단 사유와 브랜치 생성 제안을 돌려준다.
+`PreToolUse` 이벤트, matcher는 `Bash`. stdin으로 들어온 훅 페이로드에서 실행될 명령을 꺼내, **실제 `git commit` 실행인지** 판별한다. 문자열에 "commit"이 들어있는지로 보지 않고 `&&`, `||`, `;`, `|` 등 셸 연산자로 명령을 세그먼트 단위로 잘라 판별했다(우회 방지). main이면 exit 2 + 한국어 stderr로 차단 사유와 브랜치 생성 제안을 돌려준다.
 
 **설계 결정 3개와 근거:**
 
 | 결정 | 선택 | 근거 |
 |---|---|---|
-| 예외 발생 시 동작 | **절충** — 커밋으로 판별된 뒤의 예외만 차단, 판별 이전 예외는 통과 | 매처가 `Bash` 전체라 fail-closed면 모든 셸 명령이 막혀 세션이 마비된다. 폭발 반경을 커밋으로 좁혔다. |
+| 예외 발생 시 동작 | **절충**. 커밋으로 판별된 뒤의 예외만 차단, 판별 이전 예외는 통과 | 매처가 `Bash` 전체라 fail-closed면 모든 셸 명령이 막혀 세션이 마비된다. 폭발 반경을 커밋으로 좁혔다. |
 | 설정 파일 위치 | **`.claude/settings.json`** (커밋되는 쪽) | 이번 주 결론이 "규칙은 커밋되어야 존재한다"인데 로컬 전용 파일에 넣으면 자기모순이다. |
 | 차단 범위 | **main만** (master 제외) | 이 저장소에 master는 존재하지 않는다. 존재하지 않는 브랜치를 막는 규칙은 **문서에 없는 규칙을 강제하는 역방향 불일치**를 만든다. |
 
-**"조용한 죽음" 대책:** fail-open으로 통과시키는 모든 예외는 `hook_errors.log`에 시각·에러 내용을 남기고 stderr에도 경고를 출력한다. 훅이 조용히 죽어서 "요즘 커밋 잘 되네"로 보이는 상황이 곧 이번 주에 겪은 "규칙이 조용히 유실된" 사건의 재판이기 때문이다. 단위 테스트용 샘플 JSON 3개도 파일로 저장해 언제든 재실행할 수 있게 했다.
+**"조용한 죽음" 대책:** fail-open으로 통과시키는 모든 예외는 `hook_errors.log`에 시각, 에러 내용을 남기고 stderr에도 경고를 출력한다. 훅이 조용히 죽어서 "요즘 커밋 잘 되네"로 보이는 상황이 곧 이번 주에 겪은 "규칙이 조용히 유실된" 사건의 재판이기 때문이다. 단위 테스트용 샘플 JSON 3개도 파일로 저장해 언제든 재실행할 수 있게 했다.
 
 **어떻게 연동했나:** `/commit` 실행 → Claude가 Bash 도구로 `git commit` 호출 시도 → PreToolUse 훅이 그 앞에서 가로채 판별 → 차단이면 stderr가 Claude에게 피드백으로 전달된다. 즉 **커맨드는 편의, 훅은 강제**로 관심사를 분리했다.
 
 **검증 결과와 한계 (정직하게):**
-- 단위 테스트 11/11 통과 — (a) main에서 `git commit` → exit 2 (b) 다른 브랜치 → exit 0 (c) `git status` → exit 0, 오탐/미탐 8케이스 전부 통과. fail-open 경로(깨진 JSON → 통과 + 로그 + 한글 안 깨짐)도 별도 확인.
+- 단위 테스트 11/11 통과. (a) main에서 `git commit` → exit 2 (b) 다른 브랜치 → exit 0 (c) `git status` → exit 0, 오탐/미탐 8케이스 전부 통과. fail-open 경로(깨진 JSON → 통과 + 로그 + 한글 안 깨짐)도 별도 확인.
 - **라이브 검증은 미완이다.** 설정은 세션 시작 시 로드되므로 Claude Code 재시작 후에 실제 차단을 확인해야 하는데, 이번 주 범위 안에서 거기까지 가지 못했다. 커밋: `d871245`, PR: 
 https://github.com/yenachang924/popketmon-server/pull/7
-- **범위의 한계**: 이 훅이 잡는 것은 `git commit`뿐이다. `git merge`·`rebase`·`cherry-pick`·`push origin main`은 안 잡는다. 특히 **`git pull`은 내부적으로 fetch + merge라 main을 바꾸는데도 명령 문자열이 "pull"이라 어떤 확장으로도 안 걸린다.**
+- **범위의 한계**: 이 훅이 잡는 것은 `git commit`뿐이다. `git merge`, `rebase`, `cherry-pick`, `push origin main`은 안 잡는다. 특히 **`git pull`은 내부적으로 fetch + merge라 main을 바꾸는데도 명령 문자열이 "pull"이라 어떤 확장으로도 안 걸린다.**
   → 훅은 실행되는 명령의 **겉면**만 본다. 그래서 이건 "main 변경 원천 봉쇄"가 아니라 **"의도적인 main 직접 작업을 눈에 띄게 만드는 장치"**다. 범위를 넓히는 것보다 한계를 정확히 아는 쪽을 택했다.
 
 ---
@@ -98,12 +98,12 @@ https://github.com/yenachang924/popketmon-server/pull/7
 
 ## 5. 회고
 
-**겪은 삽질 — 인코딩 3연타**
+**겪은 삽질. 인코딩 3연타**
 
-1. **한글 grep 헛방** — CLAUDE.md에서 규칙을 찾는데 한글 검색이 아무것도 못 잡았다. 인코딩 문제일 수 있어 영어 `main`으로 재검색해 음성 결과 자체를 검증했다. → **"없다"는 결과도 검증 대상이다.**
-2. **`commit.md` 화면 깨짐** — `type`으로 열었더니 한글이 전부 깨져 나왔다. 파일이 깨진 건지 화면이 깨진 건지 모르는 상태에서 관찰 포인트를 정하고("인코딩을 지정해 읽으면 복원되는가") `Get-Content -Encoding UTF8`로 확인 → **파일은 멀쩡했고 콘솔 해석이 문제였다.**
-3. **전역 설정 파일 손상** — 훅 테스트용 더미 변경을 만들려고 `echo "" >> .claude/settings.json`을 실행했는데, **새로 연 PowerShell 창이 홈 디렉토리였다.** 프로젝트 파일이 아니라 `C:\Users\yenac\.claude\settings.json`(전역 설정)이 수정됐고, PowerShell 5.1의 `>>`가 UTF-8 파일에 UTF-16 CRLF(`0D 00 0A 00`)를 덧붙여 JSON 파서가 파일 전체를 거부했다. Claude Code가 "Invalid or malformed JSON"을 뱉었다.
-   → 이번 주에 반복해서 나온 원리("PowerShell 창의 상태는 열린 순간 고정된다")가 인코딩 사고와 겹쳐 재등장한 사례. 그리고 **테스트 대상으로 하필 훅 설정 파일을 고른 것 자체가 설계 미스**였다 — 망가지면 테스트 자체가 불가능해지는 파일이었다.
+1. **한글 grep 헛방**. CLAUDE.md에서 규칙을 찾는데 한글 검색이 아무것도 못 잡았다. 인코딩 문제일 수 있어 영어 `main`으로 재검색해 음성 결과 자체를 검증했다. → **"없다"는 결과도 검증 대상이다.**
+2. **`commit.md` 화면 깨짐**. `type`으로 열었더니 한글이 전부 깨져 나왔다. 파일이 깨진 건지 화면이 깨진 건지 모르는 상태에서 관찰 포인트를 정하고("인코딩을 지정해 읽으면 복원되는가") `Get-Content -Encoding UTF8`로 확인 → **파일은 멀쩡했고 콘솔 해석이 문제였다.**
+3. **전역 설정 파일 손상**. 훅 테스트용 더미 변경을 만들려고 `echo "" >> .claude/settings.json`을 실행했는데, **새로 연 PowerShell 창이 홈 디렉토리였다.** 프로젝트 파일이 아니라 `C:\Users\yenac\.claude\settings.json`(전역 설정)이 수정됐고, PowerShell 5.1의 `>>`가 UTF-8 파일에 UTF-16 CRLF(`0D 00 0A 00`)를 덧붙여 JSON 파서가 파일 전체를 거부했다. Claude Code가 "Invalid or malformed JSON"을 뱉었다.
+   → 이번 주에 반복해서 나온 원리("PowerShell 창의 상태는 열린 순간 고정된다")가 인코딩 사고와 겹쳐 재등장한 사례. 그리고 **테스트 대상으로 하필 훅 설정 파일을 고른 것 자체가 설계 미스**였다. 망가지면 테스트 자체가 불가능해지는 파일이었다.
 
 **워크플로우가 어떻게 바뀌었나**
 
diff --git a/members/yenachang924/week03.md b/members/yenachang924/week03.md
new file mode 100644
index 0000000..e144eea
--- /dev/null
+++ b/members/yenachang924/week03.md
@@ -0,0 +1,29 @@
+# Week 03 – 기획 & 착수: 빵킵
+
+- 작성자: yenachang924
+
+> 이번 주 한 줄: **"만들기 전에 죽여본다. 현장 30곳, 0곳."**
+
+## 0. 무엇을, 왜
+
+**빵킵**. 품절 전에 원하는 빵을 확보하고 싶은 손님과, 생산량을 감으로 정하는 동네 빵집 사장님을 잇는 **선결제 픽업 예약**.
+기획서(idea.md) 10항목의 핵심은 '하지 않는 것' 둘이었다: **실시간 재고 입력 없음**(사장님은 아침 1회), **할인 없음**(파는 것은 싼 빵이 아니라 "가면 반드시 있다"는 확실함).
+
+## 1. 한 것
+
+- **현장 검증**. 망원, 연남 30곳을 직접 돌았다. 손님으로 사보고, 사장님과 이야기했다. 픽업 예약을 받는 곳은 **0곳**. 한 인기 빵집은 프로필에 "빵 예약 안됩니다", 다른 곳은 영업시간이 "소진시마감". 사장님 말: **"수량을 알릴 수 있는 데가 인스타밖에 없어요. 하나로 모이면 좋겠는데."**. 공급자 쪽 니즈를 당사자 입으로 확인한 것이 이 기획의 가장 강한 카드가 됐다.
+- **범위 자르기**. 6주 MVP는 (1) 사장님 입력 → 예약 페이지 (2) 손님 시간대 선택, 선결제 (3) 픽업, 취소. 범위 밖: 실시간 재고, 실 PG 정산, 네이티브 앱.
+- **셋업**. Next.js 16(App Router, Server Actions) 단일 앱, `CLAUDE.md`(→ `AGENTS.md`)에 규약을 **에이전트가 지킬 수 있는 문장**으로: 시간은 `time.ts` 한 곳, 결제는 `payments/` 한 곳, 외부는 게이트웨이 뒤.
+- **사업계획서, 발표 대본** , 
+
+## 2. 막힌 것
+
+
+## 3. 배운 것
+
+- "왜 만드나"를 **내 불편**에서 시작했지만, 기획서에 들어간 건 **사장님의 문장**이었다. 수요는 내가 알고, 공급은 현장이 알려줬다.
+- 기획서의 "대안, 경쟁" 칸이 제일 오래 걸렸다. 네이버 예약은 '시간, 좌석' 모델, 공동구매는 '사람이 모여야 성사', 마감 할인은 '랜덤'. 빵킵은 **오픈의 지명**.
+
+## 4. 다음 주
+
+- 유사 서비스 코드 부검 → 설계 → MVP 한 바퀴(발행, 킵, 취소, 픽업) → 결제 코어 테스트
diff --git a/members/yenachang924/week04.md b/members/yenachang924/week04.md
new file mode 100644
index 0000000..4e70d1e
--- /dev/null
+++ b/members/yenachang924/week04.md
@@ -0,0 +1,29 @@
+# Week 04 – 개발 1: MVP 한 바퀴 + 증거
+
+- 작성자: yenachang924
+
+> 이번 주 한 줄: **"주장 대신 측정. 동시 200 vs 10, 오버셀 0."**
+
+## 1. 한 것
+
+- **맨땅 대신 부검** ([ADR-001](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/001-reference-autopsy.md)). 같은 시장의 유사 서비스 FE/BE를 탐색 에이전트 2개 병렬로 전수 분석(~30만 토큰). 결과를 **가져올 것 / 버릴 것 / 달라야 할 것** 3분류로 먼저 적고 설계를 시작했다. 가져옴: 결제 신뢰 경계, 조건부 원자 UPDATE, 픽업 UX. 버림: 목표수량 달성형 상태머신, 운영자 건별 승인, 정산, 어드민 풀스택. 달리함: **시간대(BakeSlot)가 1급 엔티티**, 요일 템플릿, 1명이어도 즉시 확정.
+- **MVP 전체 플로우**. 시간표 발행 → 킵(선결제) → 취소, 환불 → 픽업(코드/QR 검증). Server Actions + Prisma 6(7에서 다운그레이드, [ADR-003](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/003-sqlite-prisma6.md)).
+- **결제 5원칙을 코드로** ([ADR-005](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/005-payment-trust-boundary.md)). 금액은 서버 확정, PG 재조회, 조건부 원자 UPDATE, 멱등, 감사로그. 사업자등록 전이라 **PG를 인터페이스 뒤에 두고 모의 PG로**([ADR-006](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/006-payment-gateway-abstraction.md)). 제약이 추상화를 낳았다.
+- **증거**. 결제 코어 테스트 12개, GitHub Actions CI. 동시성 증명: 잔여 10개에 동시 200명 → 예약 10, **오버셀 0**, 190명 자동 환불([proof](https://github.com/yenachang924/bbangkeep/blob/main/docs/proof/concurrency-latest.md)). 부하 실측: 읽기 p99 360ms @ 210rps.
+- ADR 8건, 주간 로그 시작([docs/log](https://github.com/yenachang924/bbangkeep/tree/main/docs/log)), 아티클 #0 초안.
+
+## 2. 막힌 것
+
+- **환불 순서 창**. "PG 환불 성공 → DB 반영 실패" 사이. 당시엔 감사로그 기반 수동 복구를 전제로 "알려진 구멍"으로 ADR에 적어두고 넘어갔다(멘토링 질문으로).
+- Prisma 7의 파괴적 변경 → 6으로 명시적 다운그레이드. "최신"이 아니라 "지금 나를 빠르게 하는 버전".
+- Windows: python cp949 인코딩, 브라우저 pane 스크린샷 불가 → `PYTHONUTF8=1`, Playwright headless로 우회.
+
+## 3. 배운 것
+
+- **재고 차감을 단일 방어로**. 레퍼런스의 3중 방어에서 2개를 근거 있게 뺐다([ADR-004](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/004-atomic-update-inventory.md)). 뺀 이유와 "인스턴스 2대+면 재검토"를 같이 적어야 뺀 것이 된다.
+- 결정마다 **재검토 조건**을 적어두니 "왜 이렇게 했지?"가 "이 조건이 바뀌면 다시 본다"로 바뀐다.
+
+## 4. 다음 주
+
+- SQLite 쓰기 한계 실측 → Postgres 전환 → Vercel 배포(파일럿 가게 앞에 세울 상태)
+- 킬 기준: 부하 테스트에서 오버셀 1건이면 기능 추가 중단
diff --git a/members/yenachang924/week05.md b/members/yenachang924/week05.md
new file mode 100644
index 0000000..23aa901
--- /dev/null
+++ b/members/yenachang924/week05.md
@@ -0,0 +1,27 @@
+# Week 05 – 개발 2: 배포와 인수인계 문서
+
+- 작성자: yenachang924
+
+> 이번 주 한 줄: **"배포는 끝이 아니라 조건의 변경이다. SQLite의 재검토 조건이 발동했다."**
+
+## 1. 한 것
+
+- **Postgres 전환 + Vercel 배포**. [ADR-003](https://github.com/yenachang924/bbangkeep/blob/main/docs/adr/003-sqlite-prisma6.md)에 적어둔 전환 조건(배포 시점, 파일 DB 비영속)이 발동. 스키마 provider 전환, raw SQL 식별자 인용, Vercel 빌드 스크립트. 운영 `public` / 로컬 `dev` / 테스트 `bk_test` **스키마 3단 격리**. 라이브: https://bbangkeep.vercel.app
+- **CI를 컨테이너 Postgres로**. 운영 DB를 CI에서 건드리지 않도록 서비스 컨테이너로 전환. `demo:reset`에 운영 스키마 가드(public이면 중단, 우회는 명시 플래그).
+- **디자인 전면 개편**. 토스 디자인 언어(라이트) + 다크 테마를 토큰 반전만으로. 하단 탭 내비.
+- **ADR-002에 '계획된 분리' 조건 추가**. 결제, 재고 도메인을 Spring으로 이식해 같은 테스트, 같은 숫자를 재현하는 것을 재검토 조건으로 명시.
+- **HANDOFF.md**. 환경, 규약, 우선순위 백로그, 금지사항을 한 문서로. "다음에 이 레포를 여는 에이전트/사람이 이것만 읽으면 된다"를 목표로.
+
+## 2. 막힌 것
+
+- 원격 Render DB(싱가포르)로 로컬 테스트를 돌리면 동시성 테스트가 60초 타임아웃. 환경 문제. CI는 컨테이너라 그린. 로컬 `.env`의 `?schema=dev`와 테스트의 `&schema=bk_test`가 겹치면 Prisma가 첫 파라미터를 쓰는 함정(6주차에 '교체+public 차단'으로 고침).
+
+## 3. 배운 것
+
+- 전환 조건을 미리 적어두면 전환이 **사건이 아니라 절차**가 된다.
+- CI가 운영 DB를 보는 구조는 "빠르다"가 아니라 "위험하다"였다. 격리에 드는 1분이 싸다.
+
+## 4. 다음 주
+
+- 사장님 AI 비서(한 줄 발행). LLM도 PaymentGateway처럼 게이트웨이로, 초안은 사람이 승인
+- 데모데이(8/23) 시연 준비
diff --git a/members/yenachang924/week06.md b/members/yenachang924/week06.md
new file mode 100644
index 0000000..ecd7dba
--- /dev/null
+++ b/members/yenachang924/week06.md
@@ -0,0 +1,21 @@
+# Week 06 마무리
+
+- 작성자: yenachang924
+
+## 한 것
+- HANDOFF.md와 프롬프트 한 장으로 새 세션을 시작하고, 기능을 PR 단위로 받아 읽고 머지했다. 사장님 AI 비서, PortOne 웹훅, MCP 서버, 알림 게이트웨이, 보드 모드, E2E, 마이그레이션, HTTP 계약, Spring 골격, 폴더 분리(frontend, backend, docs), 디자인 정리.
+- 코드 리뷰와 보안 리뷰를 독립 세션 2개로 돌리고 같은 날 반영했다. 취소 경로에 조건부 갱신이 없던 것, 환불 실패가 보이지 않던 것 등.
+- 배포 뒤 느린 원인을 찾았다. 서버 함수는 미국, DB는 싱가포르였다. 리전 설정 한 줄로 해결.
+- README를 "어떤 기술을 왜 썼나" 표로 다시 썼다.
+
+## 막힌 것
+- 사용자가 아직 없다.
+- 데모 계정 비밀번호 교체, 시크릿 정리는 사람 몫으로 남아 있다.
+
+## 배운 것
+- 문서가 있다는 것과 문서로 일이 된다는 것은 다르다. HANDOFF가 작동하는지는 새 세션이 실제로 기능을 만들어야 안다.
+- 에이전트에게 가장 중요한 지시는 "어떻게"가 아니라 "하지 말 것"이었다.
+- 같은 모양(게이트웨이)을 세 번 쓰니 세 번째부터는 내가 먼저 구조를 말했다.
+
+## 다음
+써 줄 가게 한 곳 찾기. Spring approve, cancel은 내 손으로.