docs: align PR evidence with docker workflow

Author: jay20012024

docker-compose.yml

@@ -36,8 +36,10 @@ services:
   frontend:
     build:
       context: ./frontend
+      args:
+        NEXT_PUBLIC_API_BASE_URL: ${NEXT_PUBLIC_API_BASE_URL:-http://localhost:8000}
     environment:
-      NEXT_PUBLIC_API_BASE_URL: http://localhost:8000
+      NEXT_PUBLIC_API_BASE_URL: ${NEXT_PUBLIC_API_BASE_URL:-http://localhost:8000}
     ports:
       - "3000:3000"
     depends_on:

docs/assets/commitgram-workflow-home.png

@@ -59,8 +59,8 @@ git config core.hooksPath .githooks
   - 개선: `docs/weekly-plan.md`, `docs/design-review.md`, `docs/architecture.md`로 계획, 설계 리뷰, 구조 설명을 분리했다.
 - 문제점: PR 본문과 스크린샷은 템플릿만 있고 실제 제출 증빙이 부족했다.
   - 개선: `docs/pr-description.md`에 채워진 PR 본문 초안을 만들고, `docs/assets/commitgram-workflow-home.png`를 추가했다.
-- 문제점: Docker가 없는 환경에서는 compose 기반 검증을 바로 수행할 수 없었다.
-  - 개선: backend/frontend 개발 서버를 직접 실행하고 Playwright로 동일한 mock 로그인 화면을 캡처하는 대체 검증 경로를 사용했다.
+- 문제점: frontend의 `NEXT_PUBLIC_API_BASE_URL`은 runtime 환경변수만으로는 browser bundle에 반영되지 않는다.
+  - 개선: Docker build arg로 API base URL을 주입하고, Playwright base URL도 환경변수로 바꿔 검증 포트를 유연하게 만들었다.
 
 ## PR Notes
 

docs/design-review.md

@@ -18,13 +18,13 @@ PR 제목: `[학부명_실명] - AI 개발 workflow와 서비스 구조 문서
 - 요구사항을 한 문장으로 재정의: 기능 구현보다 AI를 활용한 분석/설계 workflow를 설명 가능한 산출물로 남기는 것이 목표라고 정리했습니다.
 - 확인한 기존 구조: README, docs, frontend feature 구조, backend domain module 구조, CI/hook 적용 위치를 먼저 확인했습니다.
 - 이슈 분리 방식: workflow 문서화, Skill 적용, Hook 적용, 서비스 아키텍처 설명, PR 작성 workflow 고정으로 나눴습니다.
-- 선택한 검증 방법: hook 문법 확인, pre-commit hook 실행, 실제 앱 화면 캡처를 통해 문서와 workflow가 동작 가능한 상태인지 확인했습니다.
+- 선택한 검증 방법: hook 문법 확인, pre-commit hook 실행, Docker compose 기동, 실제 앱 화면 캡처를 통해 문서와 workflow가 동작 가능한 상태인지 확인했습니다.
 
 ## 가장 막혔던 순간
 
-- 막힌 지점: 동작 화면 스크린샷을 만들기 위해 Docker compose를 실행하려 했지만 현재 WSL 환경에서 Docker 명령을 사용할 수 없었습니다.
-- AI에게 다시 질문한 방식: “Docker가 없을 때 같은 mock 환경을 어떻게 재현해서 스크린샷을 만들 수 있는가?”라는 방향으로 실행 방법을 바꿨습니다.
-- 해결 방법: backend와 frontend 개발 서버를 직접 실행하고, Playwright로 mock GitHub 로그인 후 실제 화면을 캡처했습니다.
+- 막힌 지점: Docker compose 환경에서 frontend가 browser bundle을 빌드할 때 `NEXT_PUBLIC_API_BASE_URL`이 runtime 환경변수만으로는 반영되지 않는 점이 헷갈렸습니다.
+- AI에게 다시 질문한 방식: “Next.js public 환경변수는 Docker build와 runtime 중 어느 단계에서 반영되는가?”를 기준으로 원인을 좁혔습니다.
+- 해결 방법: Docker build arg로 API base URL을 주입하고, Playwright base URL도 환경변수로 분리해 compose 환경에서 검증할 수 있게 했습니다.
 
 ## 새로 알게 된 것
 

docs/pr-description.md

@@ -79,7 +79,7 @@ AI를 활용하기 위한 설계 과정을 이해하고, 반복 가능한 Agent
 - 목표: 보수적인 채점 기준에서도 확인 가능한 PR 본문과 스크린샷을 준비한다.
 - 설계 질문: 템플릿 준비와 실제 제출 내용 작성은 어떻게 구분할 것인가?
 - 완료 조건: `docs/pr-description.md`에 채워진 PR 본문이 있고, `docs/assets/commitgram-workflow-home.png`에 실제 화면 캡처가 있다.
-- 검증: 문서에서 스크린샷 링크가 열리고, PR 본문에 완료 작업/설계 과정/막힌 점/배운 점/개선점이 모두 채워져 있다.
+- 검증: Docker compose 환경에서 E2E를 통과하고, PR 본문에 완료 작업/설계 과정/막힌 점/배운 점/개선점이 모두 채워져 있다.
 
 ## 나의 Agent 개발 Workflow
 

docs/weekly-plan.md

@@ -5,6 +5,8 @@ RUN npm ci
 
 FROM node:22-alpine AS builder
 WORKDIR /app
+ARG NEXT_PUBLIC_API_BASE_URL=http://localhost:8000
+ENV NEXT_PUBLIC_API_BASE_URL=$NEXT_PUBLIC_API_BASE_URL
 COPY --from=deps /app/node_modules ./node_modules
 COPY . .
 RUN npm run build

frontend/Dockerfile

@@ -4,7 +4,7 @@ export default defineConfig({
   testDir: "./e2e",
   timeout: 30_000,
   use: {
-    baseURL: "http://localhost:3000",
+    baseURL: process.env.PLAYWRIGHT_BASE_URL ?? "http://localhost:3000",
     channel: "chrome",
     trace: "retain-on-failure",
   },