<!-- task=m-gito-branch-event-creation-sync-bridge/02+01_creation_enqueue_bridge plan=1 tag=REVIEW_GITO_CREATION_ENQUEUE -->

# Plan: Review Gito Creation Enqueue Bridge

## 메타
- Milestone: `gito-branch-event-creation-sync-bridge`
- Build grade: cloud-G07
- Mode: review-follow-up
- Scope: `ProviderRevision`에 mutable Plane state를 넣어 durable idempotency가 conflict로 깨지는 문제를 수정한다.

## Roadmap Targets
- `agent-roadmap/phase/agent-ops-mcp-control-plane/milestones/gito-branch-event-creation-sync-bridge.md`
- Task IDs:
  - `[revision-scan]`
  - `[creation-enqueue]`
  - `[runtime-wiring]`
- Completion mode: check-on-pass

## 범위 결정 근거
- 이전 리뷰 로그: `code_review_cloud_G07_0.log`
- Required 이슈는 `services/core/internal/gitosync/bridge.go`의 job args 구성과 이를 고정하는 테스트에 한정된다.
- public HTTP API, Gito event DTO, scanner git command flow, server wiring은 이번 후속 범위에서 바꾸지 않는다.

## 구현 지시
- 구현 중 사용자에게 직접 질문하거나 선택지를 제시하지 않는다.
- 사용자만 결정할 수 있는 blocker가 실제로 생기면 `CODE_REVIEW-cloud-G07.md`의 `사용자 리뷰 요청` 섹션을 채우고 active 파일을 둔 채 중단한다.
- 검증 증거 부족은 사용자 리뷰 요청이 아니라 후속 에이전트가 재실행할 수 있는 일반 구현/검증 작업으로 처리한다.

## 구현 계획

### REVIEW_GITO_CREATION_ENQUEUE-1. ProviderRevision 안정화
- 문제: `Bridge.enqueueDoc`가 `workitem.WorkItem.State`를 `scheduler.RoadmapCreationSyncJobArgs.ProviderRevision`에 넣는다. Sync가 Plane state를 Todo로 이동한 뒤 같은 roadmap revision이 재처리되면 기존 identity의 provider revision과 새 trigger provider revision이 달라져 completed ledger 확인 전에 conflict가 날 수 있다.
- 해결:
  - Gito develop push bridge에는 안정적인 provider revision token이 없으므로 `ProviderRevision`을 비워 둔다.
  - `RoadmapRevision`은 develop revision으로 유지해 다른 develop revision 재처리는 기존 conflict guard가 계속 잡게 한다.
  - `bridge_test.go`에서 Plane `State`가 있어도 enqueued job의 `ProviderRevision`이 비어 있음을 검증한다.
  - 필요한 경우 `Bridge`/job args 주석을 조정해 mutable state를 revision으로 쓰지 않는 이유를 짧게 남긴다.

## 구현 체크리스트
- [ ] `services/core/internal/gitosync/bridge.go`에서 `ProviderRevision`에 Plane `State`를 전달하지 않는다.
- [ ] `services/core/internal/gitosync/bridge_test.go`에 Plane state가 `ProviderRevision`으로 매핑되지 않는 회귀 테스트를 추가하거나 기존 exact args 테스트에 명시 assertion을 더한다.
- [ ] 같은 roadmap revision 재처리는 mutable provider state가 달라도 revision conflict를 만들지 않고, 다른 roadmap revision은 기존 `RoadmapRevision` guard로 보호된다는 의도를 코드/테스트에서 확인한다.
- [ ] `cd services/core && go test -count=1 ./internal/gitosync ./internal/roadmapsync ./internal/roadmapsyncpipeline ./internal/scheduler`를 실행하고 결과를 `CODE_REVIEW-cloud-G07.md`에 기록한다.
- [ ] `cd services/core && go test -count=1 ./...`를 실행하고 결과를 `CODE_REVIEW-cloud-G07.md`에 기록한다.
- [ ] `cd services/core && go vet ./...`를 실행하고 결과를 `CODE_REVIEW-cloud-G07.md`에 기록한다.
- [ ] `git diff --check`를 실행하고 결과를 `CODE_REVIEW-cloud-G07.md`에 기록한다.
- [ ] `CODE_REVIEW-cloud-G07.md`의 구현 항목별 완료 여부, 구현 체크리스트, 계획 대비 변경 사항, 주요 설계 결정, 검증 결과를 모두 채운다.

## 리뷰어 체크포인트
- `ProviderRevision`이 빈 값이면 `roadmapsync.mismatch`가 conflict를 만들지 않는 기존 계약과 맞는가.
- `RoadmapRevision`은 그대로 유지되어 다른 develop revision 재처리 conflict guard가 약해지지 않는가.
- 테스트가 mutable Plane state를 revision으로 쓰지 않는 계약을 직접 검증하는가.

## 최종 검증
- `cd services/core && go test -count=1 ./internal/gitosync ./internal/roadmapsync ./internal/roadmapsyncpipeline ./internal/scheduler`
- `cd services/core && go test -count=1 ./...`
- `cd services/core && go vet ./...`
- `git diff --check`
