[Task] GRB-04 backend verification contract 정규화

[alexization]

대상 저장소

git-ranker

요약

현재 git-ranker에는 pre-harness 시기에 쌓인 backend verification surface가 Gradle task, GitHub Actions, OpenAPI regeneration 문서, verification 성격의 테스트에 흩어져 있다. 이 상태를 유지한 채 새 harness 기준 contract를 얹으면 명령 entrypoint, 실패 의미, CI lane 소유권이 섞여 다음 정규화 단계가 흔들린다.

왜 지금 필요한가요?

GRW-15 이후 repo-specific verification contract는 상위 registry와 맞는 형태로 다시 잠겨야 한다. 먼저 legacy verification 자산을 걷어내지 않으면 GRB-04가 "현재 구현을 문서화하는 작업"으로 밀려나고, stale command와 stale CI가 계속 canonical source처럼 남는다.

완료 조건 / 기대 결과

• legacy verification command surface(integrationTest, coverage gate, OpenAPI regeneration task 등)가 backend repo에서 제거되거나 더 이상 current contract처럼 보이지 않는다.
• legacy verification CI/workflow와 verification-specific 문서/테스트가 제거되어 repo가 harness 기준 재구성을 위한 clean baseline을 갖는다.
• workflow exec plan에 제거 범위, 남은 baseline, 후속 재구성 전제조건이 기록된다.

이번 이슈에서 다루는 것

• build.gradle의 legacy verification task/plugin/dependency 정리
• .github/workflows/의 legacy verification CI 제거
• verification-specific 문서와 테스트 자산 정리
• control-plane exec plan에 cleanup evidence 기록

이번 이슈에서 다루지 않는 것

• 새로운 harness-aligned verification contract 구현
• backend 기능 변경 또는 public API 동작 변경
• frontend repo 변경

접근 메모

기존 verification surface를 먼저 비워 clean baseline을 만든다. 그 다음 후속 단계에서 current harness registry(backend-change)에 맞는 명령, 문서, CI를 새로 정의한다.

영향 / 의존성

• 기존 PR CI 검증 lane이 일시적으로 제거된다.
• 후속 GRB-04 재구성 단계에서 새 verification contract와 CI를 다시 추가해야 한다.

리스크 / 확인이 필요한 점

• integration/coverage/OpenAPI 관련 기존 자동 검증이 비활성화되므로 후속 정렬 전까지는 repo-local automated guardrail이 줄어든다.
• tracked OpenAPI snapshot과 verification-specific test 정리 범위를 새 contract 도입 전에 다시 고정해야 한다.

참고 자료

• git-ranker-workflow/docs/product/work-item-catalog.md
• git-ranker-workflow/docs/operations/verification-contract-registry.md
• git-ranker-workflow/docs/exec-plans/completed/2026-03-26-grb-02-backend-verification-hardening.md