docs(review): add independent Gitea code review workflow

harness/agents/review/skills/gitea-code-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: gitea-code-review
+description: Spec pass된 Gitea PR의 코드 품질과 안전성을 검토한다.
+version: 0.1.0
+author: genichin, Hermes Agent
+license: MIT
+platforms: [linux]
+metadata:
+  hermes:
+    tags: [gitea, review, security, testing]
+    related_skills: [gitea-implementation-spec-review, gitea-issue-rework]
+---
+
+# Gitea Code Review
+
+`구현 → spec pass → code review`의 독립 2차 리뷰를 수행한다. 승인된 요구사항을 바꾸거나 직접 구현하지 않고, 코드 결함과 검증 부족을 근거로 판정한다.
+
+## 사용 시점과 정본
+
+- Exact `owner/repository`, source Issue와 PR을 지정해 코드 리뷰 또는 재리뷰를 요청받았을 때 사용한다.
+- 작업마다 `read_file`로 [Gitea access](../../../../operations/gitea-access.md)와 [Repository cache](../../../../operations/repository-cache.md)를 읽는다. 인증·경로·권한·잠금은 이 공통 지침을 따른다.
+- 현재 Issue의 승인된 Discovery가 계약 정본이다. 필요한 문서 규칙만 harness의 `docs/`에서 읽는다.
+- 구현, Discovery 수정, merge와 release에는 사용하지 않는다.
+
+## 진입 조건
+
+1. 식별자와 review role의 인증 출처·stable account ID를 검증한다. Impl 및 spec role과 다른 identity여야 하며 다른 role credential로 fallback하지 않는다.
+2. PR이 open이고 source Issue에 exact `Closes #<issue-number>` 하나로 연결되며 default branch를 base로 하는지 확인한다.
+3. 현재 계약 digest와 PR full head SHA에 결합된 spec-agent의 `approve/APPROVED` native review를 확인한다. Author, body binding, stale·dismissed 상태를 검증한다. 이전 head의 pass나 구현자의 pass 주장은 인정하지 않는다.
+4. Issue 계약, PR base·head, 전체 changed files·diff·reviews·review comments와 CI/status를 snapshot으로 보존한다. Pagination 누락, truncated diff, 계약 모순 또는 identity 불명은 차단한다.
+
+완료 조건: 현재 head와 계약에 대한 유효한 spec pass 및 완전한 리뷰 입력이 있다. 실패하면 read-only blocker를 보고하고 native review를 게시하지 않는다.
+
+## 리뷰 관점
+
+- **정확성·회귀:** 조건 분기, 경계값, 상태 전이, 데이터 처리와 기존 호출자에 대한 부작용.
+- **보안:** 인증·인가, 입력 검증, injection·경로 탈출, secret 노출, cookie·origin·proxy trust와 fail-closed/no-call/no-write 경계.
+- **동시성·복구:** race, 원자성, 잠금 순서, timeout·retry·중복 처리, 부분 실패와 자원 정리.
+- **테스트·근거:** 정상·실패·경계·회귀 검출력, mock의 한계, 실제 runtime 경로와 실행 provenance.
+- **성능·구조:** 과도한 I/O·반복 호출·무제한 자원 사용, 책임·의존 방향, dependency·lockfile·설치 설정과 문서 정합성.
+
+`terminal`로 Git diff를 확인하고 `read_file`로 모든 변경 파일과 필요한 주변 코드·테스트를 읽는다. 스타일 취향이나 승인 범위 밖의 기능을 필수 변경 요청으로 만들지 않는다. 계약 위반과 명세 자체의 결함을 구분한다.
+
+## 실행 검증과 기존 워크트리 사용
+
+전체 테스트를 매번 재실행할 필요는 없다. Exact-head CI와 신뢰 가능한 실행 기록을 평가하고, 위험하거나 근거가 부족한 부분을 직접 검증한다. Command evidence에는 명령, exit code, 관련 출력, 환경과 source revision이 있어야 한다. 다른 revision의 기록은 전체 후속 diff와 실행 입력의 동일성을 증명한 경우에만 재사용하며 독립 실행과 구분한다.
+
+별도 워크트리는 만들지 않는다. 기존 impl Issue 워크트리는 다음 조건을 모두 만족할 때 **검증 전용으로 대여**한다. 구현 재개가 아니므로 `state.json`의 `created_by_role`은 impl role로 확인·보존하고 review role로 바꾸지 않는다.
+
+1. Workflow 동안 exact Issue lock을 유지한다. Cache·registration 검증에는 `issue lock → repository lock` 순서를 사용하고, 테스트 전에 repository lock만 해제한다.
+2. Canonical path·권한·state identity·common Git directory·detached/locked registration을 검증한다. HEAD는 현재 PR head와 같고 미완료 Git operation과 tracked 변경이 없어야 한다.
+3. Untracked 파일, dependency 환경과 설정이 검증을 오염시키지 않는지 확인한다. 설명할 수 없는 상태는 reset·clean·stash·checkout으로 복구하지 않고 중단한다.
+4. Source·test·Git refs·state는 수정하지 않는다. 테스트 출력·fixture·DB는 격리된 임시 경로를 사용하고 운영 데이터·credential을 사용하지 않는다. 파일 수정이나 위험한 외부 쓰기가 필요한 명령은 실행하지 않는다.
+5. 실행 전후 HEAD와 tracked/untracked 상태를 비교한다. 현재 실행이 만든 자원만 정리하고, 모든 종료 경로에서 lock을 역순 해제한 뒤 non-blocking 재획득·해제로 해제를 확인한다.
+
+안전한 대여가 불가능하면 CI·기존 근거를 사용하고 직접 실행 불가 사유를 보고한다. 필수 검증 근거가 부족하면 승인하지 않는다. 독립성은 reviewer의 판단과 직접 확인에 있으며 별도 checkout 자체가 필수는 아니다.
+
+## 판정과 기록
+
+- `approve`: 전체 diff, 관련 코드·테스트와 필요한 실행 근거를 검토했고 미해결 중요 결함이나 필수 검증 공백이 없다.
+- `request_changes`: 확인된 결함 또는 판정에 필요한 검증 부족이 있다.
+- `blocked`: spec pass 부재·drift, 명세 모순 또는 안전한 검토를 막는 조건이 있다. 승인하지 않고 blocker를 보고한다.
+
+Finding마다 `F-001` 같은 ID, 파일·행, 발생 조건, 영향·심각도, 확인 근거, 계약과의 관계 및 제한된 수정·재검증 방향을 기록한다. 확정 결함, 질문, 잔여 위험과 비차단 제안은 분리한다. 위임 시 exact head·계약 subset·파일 범위와 read-only 조건을 주고, main reviewer가 중요 지적을 직접 검증하며 최종 판정을 책임진다.
+
+결과는 checkout 밖의 trusted workflow artifact에 한국어로 보존한다. Target, reviewed head, contract digest, spec review ID, findings, 실행 결과·한계와 verdict를 포함한다. SHA·path·명령은 원문을 유지하고 secret은 기록하지 않는다.
+
+## Native review 게시와 재검토
+
+1. Exact PR 리뷰 요청은 진입 조건을 충족한 native review 하나의 게시만 승인한다. 단순 조사·역할 보고 요청은 write를 승인하지 않는다. `approve → APPROVED`, `request_changes → REQUEST_CHANGES`로 매핑하고 `blocked`는 게시 없이 보고한다.
+2. 게시 직전 Issue 계약, PR base·head, spec pass와 review baseline을 재확인한다. Drift면 중단한다. Body에는 결과 artifact의 요약과 아래 marker를 넣는다.
+   `<!-- gitea-agent:code-review/v1 owner=<owner> repository=<repository> issue=<issue-number> pr=<pull-number> head=<full-head-sha> contract-sha256=<digest> -->`
+3. 같은 author·head·계약의 canonical review가 하나 있고 body·최종 state가 같으면 readback 후 write 없는 no-op으로 종료한다. 중복·상충 결과 또는 PENDING이면 추가 게시하지 않는다.
+4. 실제 adapter schema를 확인하고 exact head의 `commit_id`, body, verdict-compatible state/event와 `comments: []`를 명시해 한 번 게시한다. Exact review와 complete collection을 다시 읽어 ID·author·body·head·state·stale/dismissed·inline comments 부재를 검증한다. Timeout·오류는 blind retry하지 않고 readback으로 조정하며 불확실하면 partial로 보고한다.
+5. 게시 후 계약·PR head·source Issue 내용이 보존됐는지 확인한다. Native review에 인과가 확인되는 provider 파생 변경과 무관한 mutation을 구분한다. 검증 실패를 성공으로 보고하지 않는다.
+6. 변경 요청은 기존 PR의 `gitea-issue-rework`로 전달한다. 새 head가 생성되면 **재작업 → 새 head의 spec pass → code 재리뷰**를 수행한다. 이전 지적과 근거는 활용하되 해결 여부·영향·회귀를 새 snapshot에서 확인한다. 동일 현재 head와 계약의 두 pass가 최종 승인 조건이며 merge 승인은 아니다.
+
+## 주의 및 완료 보고
+
+- Source·test·Discovery 수정, commit·push·merge, Issue 변경, review dismiss, release·deployment를 하지 않는다.
+- PR의 성공 주장, delegate 요약, process exit 또는 native state만으로 완료를 주장하지 않는다. HTTP/framework test를 실제 browser 검증으로 표현하지 않는다.
+- 보고에는 exact target·head·contract·spec review ID, 검토 범위, findings·verdict, 실제 실행과 재사용 근거, 미검증 범위, native review ID/state/readback 또는 미게시 이유, cleanup·partial 상태를 포함한다.
+- clean review는 검토 범위에서 중요 결함을 발견하지 못했다는 의미이며 무결함의 증명은 아니다.