Qwen Code 0.21.3: /review를 신뢰하기 전 PR 테스트 계획을 검증하세요

요약 (Quick answer)

Qwen Code 0.21.3은 /review 기능을 더욱 증거 기반(evidence-aware)으로 만듭니다. 이번 안정화 버전(stable release)에서는 테스트 계획 주장 검증(Test Plan claim validation), 테스트 실패에 대한 측정된 귀속(measured attribution), 그리고 추가적인 검증 관점(verification lenses)이 추가되었습니다. 중요한 변화는 "더 많은 리뷰 에이전트"를 도입하는 것이 아닙니다. 그것은 읽힌 주장(a claim that was read), 측정된 결과(a result that was measured), 그리고 실행하기에 안전한 판결(a verdict that is safe to act on) 사이의 엄격한 구분입니다.

AI 리뷰를 수락하기 전에 다음 게이트(gate)를 사용하십시오:

1. 리뷰 대상인 머지 베이스(merge base)와 PR 헤드(PR head)를 고정(freeze)합니다.
2. PR 테스트 계획(PR Test Plan)을 반증 가능한 주장(falsifiable claims)으로 변환합니다.
3. 참조된 경로(paths), 패키지 스크립트(package scripts), 그리고 보고된 테스트 횟수(test counts)를 검증합니다.
4. PR 리비전(PR revision)에서 관련 테스트를 실행합니다.
5. 실패한 명령어를 머지 베이스(merge base)에 대해 재실행(replay)합니다.
6. 실패를 신규(net-new), 공유됨(shared), 또는 측정되지 않음(unmeasured)으로 분류합니다.
7. 테스트 하네스(test harness)가 양성 대조군(positive control)을 통해 실패할 수 있음을 증명합니다.
8. 유효한 차이(effective diff), 증거(evidence), 그리고 현재 헤드(current head)가 여전히 일치할 때만 머지(merge)합니다.

이는 Qwen Code 이벤트 기반 CI 파이널라이저(event-driven CI finalizer)를 보완합니다. 해당 가이드는 CI 이후 언제(when) 승인을 확정할 수 있는지를 다룹니다. 이 가이드는 **리뷰 증거가 신뢰할 가치가 있는지(whether the review evidence deserves trust)**에 대해 답합니다.

대상 (Who this is for)

이 가이드는 Qwen Code를 사용하여 풀 리퀘스트(pull requests)를 리뷰하는 메인테이너(maintainers)를 위한 것이며, 특히 PR 설명에 테스트 계획(Test Plan)이 포함되어 있거나 저장소에 이미 불안정한(flaky) 실패 또는 기존 실패가 있는 경우에 유용합니다.

또한 자신만의 리뷰어를 구축하고 있을 때도 유용합니다. 만약 첫 번째 문제가 에이전트가 작업을 완료했음을 증명하는 것이라면, Qwen 목표 증거 체크리스트(Qwen Goal evidence checklist)부터 시작하십시오. 두 번째 구현 패턴을 원한다면, 명시적인 Claude Code 검증 워크플로우(explicit Claude Code verification workflow)를 비교해 보십시오.

무엇이 변했고 왜 중요한가 (What changed and why it matters)

공식 v0.21.3 릴리스에 따르면, 이제 /review는 변경 사항 및 워크스페이스 상태(workspace state)에 대해 테스트 계획(Test Plan)의 어설션(assertions)을 확인합니다. 또한, 실패한 파일이 수정되었는지 여부를 추측하는 대신, 베이스 트리(base tree)를 대상으로 실패한 명령을 재실행하여 실패 원인(failure attribution)을 측정합니다.

이를 통해 세 가지 일반적인 신뢰 격차(trust gaps)를 해소합니다:

Qwen의 병합된 리뷰 작업에는 효과적인 차이(effective-diff) 가드도 추가되었습니다. 빈 머지 베이스 차이(empty merge-base diff)는 리뷰를 중단시켜야 합니다. 실질적으로 축소된 차이(materially collapsed diff)는 공개되어야 하는데, 이는 PR 설명이 리뷰 중인 리비전(revision)에 더 이상 존재하지 않는 작업을 설명하고 있을 수 있기 때문입니다.

6단계 증거 워크플로우 (A six-stage evidence workflow)

1. 리뷰 정체성 동결 (Freeze the review identity)

저장소(repository), 풀 리퀘스트(pull request), 머지 베이스 SHA(merge-base SHA), 헤드 SHA(head SHA), Qwen Code 버전 및 리뷰 노력을 기록하십시오. 이후의 푸시(push)가 이전의 판결을 상속받게 하지 마십시오. 헤드가 변경되면 리뷰는 오래된 것(stale)이 됩니다.

또한 실행 중인 CLI가 의도된 빌드인지 확인하십시오. Qwen의 자체 독푸딩(dogfooding) 결과, 그렇지 않으면 서브프로세스(subprocesses)가 이전의 글로벌 바이너리(global binary)를 해석하여 새로운 게이트(gates)를 조용히 건너뛸 수 있음이 발견되었습니다.

2. 테스트 계획을 주장으로 전환 (Turn the Test Plan into claims)

확인 가능한 주장(claims)만 추출하십시오:

• 파일 또는 픽스처(fixture)가 존재하는지
• 패키지 스크립트(package script)가 정의되어 있는지
• 지정된 명령(named command)이 실행되었는지
• 결과가 수치나 상태를 보고하는지

각 주장을 confirmed(확인됨), contradicted(모순됨), differs(다름) 또는 unmeasured(측정되지 않음)로 분류하십시오. 변경된 테스트 횟수가 자동으로 모순을 의미하는 것은 아닙니다. 서로 다른 러너(runners)나 불안정한 스위트(flaky suites)가 횟수를 변경할 수 있기 때문입니다. 이는 설명이 필요한 증거입니다.

3. PR 측을 먼저 실행 (Run the PR side first)

변경된 동작을 테스트하는 가장 작은 명령들을 실행하십시오. 정확한 명령, 종료 코드(exit code), 실패한 파일 세트 및 관련 아티팩트(artifact)를 보존하십시오. "명령을 시작할 수 없음"을 "테스트 실패"로 통합하지 마십시오. 환경 오류(Environment errors)는 unmeasured에 해당합니다.

4. 머지 베이스에서 실패 재현 (Replay failures on the merge base)

실패한 모든 PR 측 명령(PR-side command)에 대해, 동일한 의존성(dependencies)과 환경을 갖춘 격리된 베이스 트리 체크아웃(isolated base-tree checkout)에서 동일한 명령을 실행합니다.

단순한 원시 수치(raw counts)가 아니라, 실패하는 **파일 세트(file sets) 또는 안정적인 식별자(stable identifiers)**를 비교하십시오. 플래키 테스트 스위트(flaky suite)는 근본적인 소유권 문제(ownership question)를 변경하지 않고도 두 번의 실행에서 서로 다른 수의 케이스를 실패시킬 수 있습니다.

5. 하네스(harness)와 유효한 차이(effective diff) 증명

통과(green) 출력을 신뢰하기 전에, 항상 실패하는 격리된 테스트나 뮤테이션(mutation)을 추가하십시오. 만약 명령이 여전히 종료 코드 0을 반환한다면, 하네스(harness)가 당신이 생각하는 것을 실행하고 있지 않은 것입니다.

그 다음 머지 베이스 차이(merge-base diff)를 다시 계산하십시오. 차이가 비어 있다면 중단하십시오. 만약 유효한 차이(effective diff)가 플랫폼이 광고하는 변경 사항보다 훨씬 작다면, 축소(collapse)된 사실을 공개하고 남은 부분만 리뷰하십시오.

GitHub 렌더링에 대한 주장은 로컬 Markdown 근사치가 아닌 실제 렌더러(real renderer)가 필요합니다. Qwen은 이러한 종류의 판결을 위해 선택적(opt-in) 스크래치 리포지토리(scratch-repository) 경로를 지원합니다. 이를 일회용으로 유지하고, 프로덕션 리포지토리를 렌더러 프로브(renderer probe)로 절대 사용하지 마십시오.

6. 제한된 평결(bounded verdict) 해결

A 리뷰는 현재의 헤드(head)가 일치하고, 모든 실질적인 테스트 계획(Test Plan) 주장이 확인되거나 설명되었으며, 하네스의 양성 대조군(positive control)이 작동하고, 새로운 차단 실패(net-new blocking failure)가 남아 있지 않을 때만 승인할 수 있습니다. 그렇지 않으면 request_changes, comment, stale, 또는 unmeasured를 반환합니다.

복사 가능한 리뷰 기록

review_evidence:
  tool: "qwen-code 0.21.3"
  base_sha: "full merge-base SHA"
...

8가지 수락 테스트 (acceptance tests)

흔한 실수

경로로부터 소유권을 추론하는 것. 수정된 파일은 오래된 실패를 드러낼 수 있는 반면, 수정되지 않은 파일은 새로운 변경 사항 때문에 실패할 수 있습니다. 두 리비전(revisions)을 모두 측정하십시오.

발견 사항이 0개인 것을 증거로 취급하는 것. 커버리지(Coverage)는 에이전트가 디프(diff)를 검사했음을 증명할 뿐, 리뷰가 충분한 식별력(discriminating power)을 가졌음을 증명하지는 않습니다.

고장 난 환경을 통한 재시도. 디스크, 프로세스 또는 의존성(dependency) 실패는 리뷰를 단락시키고(short-circuit) 측정되지 않은 것으로 공개되어야 합니다.

FAQ

Qwen Code 0.21.3을 사용하면 모든 /review 판정을 자동 병합(auto-merge)해도 안전한가요?

아니요. 증거 파이프라인(evidence pipeline)은 개선되었지만, 저장소 정책(repository policy), 환경 무결성(environment integrity), 불안정한 테스트(flaky tests), 권한(permissions) 및 인간의 승인 경계는 여전히 적용됩니다. 결과로 도출된 증거를 포괄적인 권한이 아닌, 더 강력한 병합 입력값으로 사용하십시오.

Sources

• Qwen Code v0.21.3 release
• Test Plan claim checking and base-tree harness
• Measured failure attribution
• Renderer adjudication and verification lenses
• Effective-diff guard and positive control
• Recall, fix loop, and size-derived review budget
• Qwen /review dogfooding gaps