fix(spec-review): accept implementer test reports without evidence commits

harness/agents/spec/skills/gitea-implementation-spec-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: gitea-implementation-spec-review
 description: 승인된 계약에 대해 Gitea 구현 PR 적합성을 검토한다.
-version: 0.2.0
+version: 0.2.1
 author: genichin, Hermes Agent
 license: MIT
 platforms: [linux]
@@ -84,11 +84,13 @@ reason: <bounded Korean explanation>
 - `영향 없음`으로 판정된 문서·schema·domain 영역의 변경은 범위 초과 후보로 조사한다.
 - PR의 요구사항 문서는 Discovery가 배정한 ID·경로·제목을 유지하고 `gitea-agent.requirement/v1` canonical 계약, Issue `#<issue-number>`와 구현 PR traceability를 만족해야 한다.
 - 기존 요구사항 갱신은 pinned baseline AC별 판정 조건·검증·불변조건을 현재 AC의 보존·승인된 대체·병합·삭제에 대응하고 기존 `contract`·`evidence`·`reason`에 근거를 기록한다. 구조·AC 개수만으로 충족을 판정하거나 이전 ID·개수의 동일성을 강제하지 않으며, 승인 근거 없는 검증 의미 손실은 누락으로 판정한다. 첫 누락을 발견해도 baseline AC 전체의 의미 검토를 마친 뒤 변경 요청을 확정한다. 문서 전체와 참조된 검증 근거를 함께 고려해 병합·대체를 인정하며, 필수 변경 요청에는 승인된 인수 판정 또는 검증 의미 중 무엇이 실제로 사라졌는지 설명한다. 문구·배치 차이나 동일 내용의 반복 부재만으로 누락을 판정하지 않는다.
-- Acceptance criterion마다 구현 위치와 test·status·정적 evidence가 있어야 한다. PR body의 test 성공 주장만으로 실제 file·status 또는 실행 evidence를 대체하지 않는다.
-- CI/status evidence는 exact reviewed head SHA에 결합돼야 한다. Command evidence는 command, exit code, 판정에 필요한 output, 실행 환경과 source revision의 trusted provenance를 포함해야 하며 하나라도 없으면 `indeterminate`다.
+- Acceptance criterion마다 구현 위치와 test·status·정적 evidence 또는 구현자 실행 보고를 대응한다. 구현자의 테스트 성공 보고는 구현자 실행 결과로 인정하되, 리뷰어의 독립 실행이나 CI 성공으로 표현하지 않는다. 보고만으로 실제 source·test 파일의 존재나 내용 충족을 대체하지 않으며 구현·test 검토와 보고의 검증 범위를 함께 판단한다.
+- 추가 검증은 승인된 필수 검증의 누락, 결과 간 모순, 실행 대상 불일치 또는 구체적인 위험 때문에 인수 판단이 어려운 경우에만 최소 범위로 요구한다. 별도 실행 기록의 부재만으로 `indeterminate`를 부여하거나 변경 요청을 생성하지 않는다. 필수 검증의 미수행이나 승인된 browser 검증을 unit test로 대체한 경우는 기록 부재와 구분한다.
+- CI/status evidence를 사용하는 경우 exact reviewed head SHA에 결합돼야 한다. 상세 command evidence가 제공되면 command, exit code, 판정에 필요한 output, 실행 환경과 source revision의 provenance를 검토한다. 일부 필드의 부재만으로 일률적으로 차단하지 않고 승인된 인수 조건의 판단에 실제로 미치는 영향을 설명한다. 구현자 보고, 조회한 실행 기록, reviewer 독립 실행과 CI 결과의 출처 및 확인 한계를 구분한다.
+- 승인된 요구사항 또는 저장소 계약이 명시하지 않은 한, 실행 증빙을 제품 저장소에 추가하거나 커밋하도록 요구하지 않는다. PR 본문·comment·첨부, 조회 가능한 CI artifact 또는 별도 검증 기록도 보관 위치로 인정하며 `docs/evidence` 경로나 JSON 형식을 새 필수 산출물로 만들지 않는다. Spec-review 자체의 snapshot·result artifact 보존은 trusted workflow directory의 운영 기록이며 제품 저장소의 산출물 의무와 구분한다.
 - Command evidence의 source revision과 reviewed head가 다르면 trusted provenance, ancestor 관계, 전체 source-to-head diff와 실행 입력(코드·설정·test·fixture·dependency/lockfile·실행 도구)의 변경 영향을 검증한다. 실행 입력이 동일한 evidence-only 또는 비실행 문서-only 후속 변경은 기존 실행 근거를 연결할 수 있다. 실행 입력이 변경되면 필수 계약 동작별로 기존 evidence의 유효 범위를 판단하고, 변경되지 않은 동작의 기존 관찰과 변경분의 정적·실행 근거를 함께 사용할 수 있다. 이전 실행을 현재 head에서 수행한 것으로 표시하지 않으며 파일 hash 변경만으로 전체 evidence를 무효화하거나 ancestor·일부 hash 일치만으로 승인하지 않는다. 그 조합으로도 판정할 수 없는 필수 인수 조건에만 `indeterminate`를 적용하고, 변경 요청에는 해당 조건과 필요한 최소 보완 근거를 특정한다. CI/status의 exact-head binding은 유지하며 구현자 실행 기록과 reviewer의 독립 실행을 구분해 보고한다.
 - 실패 경로, fail-closed, no-call·no-write boundary와 credential 비노출 조건은 positive-path test만으로 충족됐다고 판정하지 않는다.
-- 현재 harness에 spec-review 전용 clean worktree 계약이 없으므로 구현 Issue worktree를 spec role로 재사용하거나 임시 clone·checkout을 만들지 않는다. 독립 실행이 필요한 criterion에 authoritative CI/status 또는 신뢰 가능한 실행 evidence가 없으면 이를 숨기지 않고 `indeterminate`로 기록한다.
+- 현재 harness에 spec-review 전용 clean worktree 계약이 없으므로 구현 Issue worktree를 spec role로 재사용하거나 임시 clone·checkout을 만들지 않는다. Reviewer가 독립 실행하지 못했다는 사실은 확인 한계로 보고하고 구현자의 결함이나 자동 `indeterminate`로 전환하지 않는다. 승인 계약이 독립 실행을 명시적으로 요구하거나 위 추가 검증 조건으로 필수 인수 판단이 어려운 경우에만 해당 조건과 최소 보완 범위를 특정한다.
 
 ## Verdict 규칙
 
@@ -127,7 +129,7 @@ Native review state는 `REQUEST_CHANGES`다. 변경 요청은 기존 계약의 e
 
 Native review state는 `COMMENT`다. 구현 에이전트의 결함으로 표현하거나 임의 선택을 제안하지 않고 Discovery 재검토가 필요하다고 명시한다. Issue나 Discovery는 이 스킬에서 변경하지 않는다.
 
-`indeterminate`가 단순 구현 evidence 누락이면 `request_changes`, 명세 자체의 결함이면 `blocked_spec`으로 구분한다.
+`indeterminate`가 승인된 필수 검증의 누락, 결과 간 모순, 실행 대상 불일치 또는 구체적인 위험으로 인한 구현 측 인수 판단 불가이면 `request_changes`, 명세 자체의 결함이면 `blocked_spec`으로 구분한다. 구현 측 변경 요청에는 판단할 수 없는 exact 승인 인수 조건, 구체적인 근거와 필요한 최소 보완 범위를 기록한다. 별도 실행 로그·환경 정보·hash의 부재 또는 reviewer 독립 실행의 부재만으로 이 경로를 적용하지 않는다.
 
 ## Strict review result artifact
 
@@ -144,7 +146,7 @@ Canonical body를 렌더링하기 전에 trusted workflow directory에 JSON obje
 - `scope`는 object이고 exact key는 `missing`, `excess`, `spec_conflicts`다. 각 값은 0~512개의 중복 없는 1~4000자 string array다.
 - `conclusion`은 1~4000자의 string이다. 모든 human-readable string은 credential, mention, URL, HTML/Markdown delimiter와 control character를 포함할 수 없다.
 - Criteria 순서는 Discovery에서 추출한 계약 순서이며 같은 criterion을 중복할 수 없다.
-- `approve`에는 모든 criterion이 `satisfied`이고 세 scope array가 비어 있어야 한다. `request_changes`에는 `unsatisfied` 또는 구현 evidence 누락으로 인한 `indeterminate`가 있어야 한다. `blocked_spec`에는 `spec_conflicts` 또는 명세 결함으로 인한 `indeterminate`가 있어야 한다.
+- `approve`에는 모든 criterion이 `satisfied`이고 세 scope array가 비어 있어야 한다. `request_changes`에는 `unsatisfied` 또는 위 추가 검증 조건에 해당하는 구현 측 인수 판단 불가로 인한 `indeterminate`가 있어야 한다. 별도 실행 기록 부재만으로 이 조건을 충족하지 않는다. `blocked_spec`에는 `spec_conflicts` 또는 명세 결함으로 인한 `indeterminate`가 있어야 한다.
 - JSON parser는 duplicate key를 거부하고 exact type을 검사한다. 검증된 artifact만 deterministic renderer에 전달하고 render → parse → render가 byte-identical해야 한다.
 
 ## Canonical native review body
@@ -218,7 +220,7 @@ terminal(command="python3 harness/agents/spec/skills/gitea-implementation-spec-r
 7. Cache path·ownership·permission·bare·remote를 검증하고 canonical base repository origin에서 prune/fetch한다. Gitea default branch SHA와 local ref를 일치시키고 PR base commit object가 cache에 존재하는지 검증한다.
 8. Same-repository PR이면 head object도 cache에서 검증하고 exact base-to-head tree를 Gitea changed-file set·diff와 대조한다. Fork PR이면 target cache에 head object가 있다고 가정하지 않고 authoritative head repository·branch SHA와 Gitea changed-file set·diff를 대조한다. Diff 직렬화의 byte 차이만으로 실패시키지 않고 변경 경로와 exact base/head blob 및 hunk가 동일 변경을 나타내는지 검증한다. 임의 ref, checkout, clone 또는 worktree를 만들지 않는다.
 9. Repository lock을 해제하되 Issue lock은 유지한다.
-10. Acceptance matrix 작성 전에 기존 evidence의 source revision과 reviewed head 사이 전체 diff·실행 입력 변경을 확인하고, 필수 검증별 재사용 가능 범위와 현재 head에 새로 결합해야 할 근거를 먼저 요약한다. 재사용 여부는 위 Acceptance matrix의 기존 evidence binding 기준으로 판단하며 새 gate나 일괄 재실행 요구를 추가하지 않는다. 재검토에서는 이전 finding별 승인 계약 근거와 최소 보완 요청을 새 구현·evidence의 확인 위치에 대응하고, 해소 또는 잔여 사유를 기존 criterion의 `evidence`와 `reason`에 기록한다. 이미 충족된 검증을 source revision 차이만으로 다시 요구하지 않되, 변경 영향으로 새로 판정할 수 없어진 필수 조건은 그 근거와 최소 보완 범위를 특정한다. 이 초기 요약만으로 검토를 끝내지 않고 Approved Discovery에서 acceptance matrix를 만들고 모든 changed file, 문서, source, test와 exact-head-bound status evidence를 대응시킨다.
+10. Acceptance matrix 작성 전에 구현자 실행 보고와 상세 실행 기록의 출처 및 확인 범위를 구분한다. Revision이 식별된 기존 evidence는 source revision과 reviewed head 사이 전체 diff·실행 입력 변경을 확인하고, 필수 검증별 재사용 가능 범위와 현재 head에 새로 결합해야 할 근거를 먼저 요약한다. 상세 기록이나 revision 정보의 부재만으로 새 검증 gate를 만들지 않는다. 재사용 여부는 위 Acceptance matrix의 기존 evidence binding 기준으로 판단하며 새 gate나 일괄 재실행 요구를 추가하지 않는다. 재검토에서는 이전 finding별 승인 계약 근거와 최소 보완 요청을 새 구현·evidence의 확인 위치에 대응하고, 해소 또는 잔여 사유를 기존 criterion의 `evidence`와 `reason`에 기록한다. 이미 충족된 검증을 source revision 차이만으로 다시 요구하지 않되, 변경 영향으로 새로 판정할 수 없어진 필수 조건은 그 근거와 최소 보완 범위를 특정한다. 이 초기 요약만으로 검토를 끝내지 않고 Approved Discovery에서 acceptance matrix를 만들고 모든 changed file, 문서, source, test와 exact-head-bound status evidence를 대응시킨다.
 11. 독립 code-review worker 결과가 있으면 exact head에 바인딩됐고 authoritative하게 읽을 수 있을 때만 보조 evidence로 사용한다. 그 결과를 spec verdict로 그대로 복사하지 않는다.
 12. Verdict 규칙으로 하나의 strict result artifact와 canonical review body를 trusted workflow directory에 생성한다.
 13. Exact key/type, duplicate key, marker field, digest, deterministic correlation, criterion cardinality, path binding, verdict/state 조합, credential 부재와 render → parse → render byte equality를 검증한다.