implement-phase

name	implement-phase
description	my-bookmark 로드맵의 특정 Phase를 구현한다. 문서 숙지 → 계획 → 구현 → 검증 루프 → PROGRESS 갱신의 규율을 강제한다. 사용자가 "Phase N 구현해줘" 또는 /implement-phase N 이라고 하면 사용.
argument-hint	<phase-number>

Phase 구현 워크플로우

인자로 받은 Phase 번호(없으면 PROGRESS.md의 "다음 작업")를 구현한다. 아래 단계를 순서대로, 생략 없이 수행한다.

1. 컨텍스트 로드 (구현 금지 구간)

1. PROGRESS.md 읽기 — 현재 상태, 이전 결정, 알려진 이슈.
2. docs/09-roadmap.md의 해당 Phase 읽기 — 작업 목록, 수용 기준, 참조 문서 목록.
3. 참조 문서로 지정된 docs/*.md를 전부 읽기. 이 문서들이 스펙의 원본이다.
4. 선행 조건 확인 (예: Phase 1은 사용자의 Supabase 설정 필요). 미충족이면 구현을 시작하지 말고 사용자에게 필요한 것을 알리고 중단.
5. 기존 코드 파악: 이번 Phase가 수정할 영역의 현재 코드를 읽는다.

2. 계획

• 작업 목록을 파일 단위 계획으로 구체화한다 (생성/수정할 파일, 순서).
• TaskCreate로 작업 항목을 등록해 진행을 추적한다.
• 외부 라이브러리의 API가 확실하지 않으면 여기서 확인한다: node_modules의 타입 정의, 공식 문서. 추측 금지.

3. 구현 규칙

• AGENTS.md의 "구현 원칙"과 코딩 컨벤션을 따른다.
• 스펙(docs)과 충돌하는 상황을 만나면: 문서 우선. 문서가 현행 라이브러리 API와 맞지 않으면 현행 API를 따르되 구조는 유지하고, 결정 로그에 기록.
• 작업 단위마다 커밋 (conventional commits).
• 이번 Phase 범위 밖의 기능을 추가하지 않는다. 발견한 개선거리는 PROGRESS.md 이슈란에 적는다.

4. 검증 루프 (통과할 때까지 반복)

pnpm typecheck && pnpm lint && pnpm test && pnpm build

• 실패 → 원인 수정 → 재실행. 테스트 skip, 린트 룰 끄기, 타입 완화로 "통과시키기" 금지.
• 그 후 로드맵의 수용 기준을 하나씩 실제로 확인한다. 수동 확인 항목(UI 동작 등)은 dev 서버를 띄워 curl/브라우저 도구로 직접 검증하고, 직접 확인이 불가능한 항목은 사용자 확인 요청 목록으로 정리한다.

5. 마무리

1. PROGRESS.md 갱신: Phase 체크, 결정 로그 추가, 이슈/부채, "다음 작업" 갱신.
2. 최종 커밋: feat: complete phase N — <요약>.
3. 사용자 보고: 완료한 것 / 수용 기준 확인 결과 (사용자 직접 확인 필요 항목 명시) / 결정·이슈 요약. 검증 명령 출력 결과를 과장 없이 보고한다.