<!-- task=m-provider-adapter-foundation/01_webhook_adapter_contract plan=0 tag=API -->

# Code Review Reference - API

> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
> The task is NOT complete until every implementation-owned section below is filled in.
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
> Fill implementation-owned sections, then stop with active files in place and report ready for review.
> If implementation is blocked by a selected SDD decision or selected Milestone `구현 잠금 > 결정 필요` item, fill `사용자 리뷰 요청` with linked evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Environment/secret/service blockers, generic scope changes, repeated failures, and evidence gaps that a follow-up agent can close are normal follow-up issues, not user-review blockers by themselves.
> Do not ask the user directly, present choices in chat, or call `request_user_input` during implementation.
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only.

## 개요

date=2026-06-19
task=m-provider-adapter-foundation/01_webhook_adapter_contract, plan=0, tag=API

## 이 파일을 읽는 리뷰 에이전트에게

> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.

각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.

1. 판정을 append한다.
2. `CODE_REVIEW-local-G05.md` → `code_review_local_G05_N.log`, `PLAN-local-G05.md` → `plan_local_G05_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-provider-adapter-foundation/01_webhook_adapter_contract/`로 이동한다.
4. PASS split 작업이면 이동 후 빈 active parent 유지 여부를 확인한다.

---

## 구현 항목별 완료 여부

| 항목 | 완료 여부 |
|------|---------|
| [API-1] Provider Webhook Contract | [x] |

## 구현 체크리스트

- [x] provider webhook request, verification hook, normalization candidate, adapter interface를 `services/core/internal/provider/provider.go`에 추가한다.
- [x] fake adapter 기반 provider package 테스트를 추가해 interface 구현, empty payload 보존, candidate type/revision 표현을 검증한다.
- [x] `cd services/core && go test -count=1 ./internal/provider`를 실행한다.
- [x] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.

## 코드리뷰 전용 체크리스트

> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.

- [x] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [x] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [x] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_GNN_N.log`로 아카이브한다.
- [x] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.log`로 아카이브한다.
- [x] `.gitignore`의 Agent-Ops 관리 block을 확인한다.
- [ ] PASS이면 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [ ] PASS이면 active task 디렉터리를 archive로 이동한다.
- [ ] PASS split 작업이면 이동 후 빈 active parent를 제거하거나 유지 사유를 확인한다.
- [x] FAIL이고 user-review gate가 트리거되지 않았으므로 다음 active `PLAN-local-G03.md`와 `CODE_REVIEW-local-G03.md`를 작성하고 `complete.log`를 작성하지 않는다.

## 계획 대비 변경 사항

계획에 명시된 모든 항목을 따랐다. 추가 변경 사항 없음.

## 주요 설계 결정

1. **`WebhookEvent` 유지**: 기존 `WebhookEvent` struct를 제거하지 않고 새로운 `WebhookRequest`와 함께 유지했다. 이는 기존 API 호환성을 유지하기 위함이다.
2. **`Runtime.HandleProviderWebhook` 시그니처 변경**: `provider.WebhookEvent` → `provider.WebhookRequest`로 변경하여 headers, query, receivedAt를 직접 전달받을 수 있게 했다.
3. **router.go `handleProviderWebhook` 업데이트**: HTTP request의 `r.Header`를 `map[string][]string`으로, `r.URL.Query()`를 그대로 전달하여 `WebhookRequest`를 구성했다.
4. **`WebhookCandidate`는 string으로 `Type` 정의**: `events` package 의존을 피하기 위해 normalized event type을 string으로 유지했다.

## 검증 결과

### API-1 중간 검증

```text
$ cd services/core && go test -count=1 ./internal/provider
ok  	git.toki-labs.com/toki/gito/services/core/internal/provider	0.006s
```

### 최종 검증

```text
$ cd services/core && go test -count=1 ./internal/provider ./internal/controlplane
ok  	git.toki-labs.com/toki/gito/services/core/internal/provider	0.006s
ok  	git.toki-labs.com/toki/gito/services/core/internal/controlplane	0.651s
```

## 사용자 리뷰 요청

_기본값은 `없음`이다. 구현 중 새 결정이 필요해 보여도 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 이 섹션은 선택된 SDD 결정 또는 선택된 Milestone `구현 잠금 > 결정 필요` 항목이 실구현을 차단할 때만 채운다. 외부 환경/secret/서비스 준비, 검증 증거 공백, 반복 실패, 일반 범위 조정은 사용자 리뷰 요청이 아니며 `검증 결과`, `계획 대비 변경 사항`, 또는 code-review의 일반 follow-up plan으로 처리한다._

- 상태: 없음
- 사유 유형: 없음
- 연결 대상: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음

## 리뷰어를 위한 체크포인트

- provider package가 controlplane이나 provider-specific package를 import하지 않는지 확인한다.
- request/candidate 계약이 raw secret 저장을 요구하지 않는지 확인한다.
- dependent subtask `02+01_webhook_adapter_wiring`가 쓸 verifier/normalizer hook이 충분한지 확인한다.

---

> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**

## 코드리뷰 결과

- 종합 판정: FAIL
- 차원별 평가:
  - correctness: Pass
  - completeness: Fail
  - test coverage: Fail
  - API contract: Pass
  - code quality: Pass
  - plan deviation: Fail
  - verification trust: Pass
- 발견된 문제:
  - Required: `services/core/internal/provider/provider_test.go:79`의 fake adapter가 `WebhookRequest`를 기록하지 않고, `TestWebhookAdapterContractRequestDelivery`도 provider/event/delivery/payload/header/query가 verifier와 normalizer에 실제 전달됐는지 검증하지 않습니다. 계획의 테스트 목표가 "request의 provider/event/delivery/payload/header/query가 verifier와 normalizer로 전달됨을 확인"하는 것이므로, fake adapter에 `verifyReq`/`normalizeReq`를 저장하고 테스트에서 모든 request 필드를 assert하도록 보강해야 합니다.
- 다음 단계: FAIL 후속 plan/review를 같은 task 디렉터리에 작성한다.
