키보드 사용자가 탐지 결과(finding)를 열었을 때, 오직 "심각도 높음(High severity issue)"이라는 소리만 듣게 됩니다. 이 결과가 반복 가능한 CodeQL 쿼리에서 나온 것인지, 아니면 AI 지원 탐지(AI-assisted detection)를 통해 나온 것인지 알 수 없으며, 제안된 자동 수정(Autofix)은 이미 승인된 변경 사항처럼 보입니다. 누락된 UI 상태는 출처(provenance)와 검토 상태(review status)입니다.

GitHub는 7월 20일에 Enterprise Cloud 및 Team 사용자를 대상으로 Code Quality를 일반적으로 사용 가능(Generally Available)하게 출시했습니다. GitHub의 최신 검증된 공식 신호에 따르면 결정론적 CodeQL(deterministic CodeQL), AI 지원 탐지(AI-assisted detection), 그리고 검토 가능한 자동 수정(reviewable Autofix)을 설명하고 있습니다. GitHub의 내부 해결 지표(resolution metric)는 GitHub가 보고하는 것이며, 접근성이나 보편적 품질 벤치마크가 아닙니다. 저는 7월 27일의 더 최신의 신뢰할 수 있는 공식 릴리스를 찾지 못했으며, 검증되지 않은 2차 주장들은 거부했습니다.

워크플로와 모델 증거를 분리하기

type Finding = {
  id: string;
  title: string;
...

origin은 탐지 결과가 어떻게 생성되었는지를 나타내며, 그것이 정확한지 여부는 말해주지 않습니다. fix.status는 인간의 워크플로 결정을 기록하며, 출처를 다시 쓰는 것이 아닙니다. 이 차원들을 독립적으로 유지하십시오.

작은 의미론적 카드(Semantic Card)

<article aria-labelledby="f-17-title">
  <h3 id="f-17-title">Unsanitized redirect target</h3>
  <p><strong>Detection:</strong> Deterministic CodeQL rule</p>
...

색상이나 아이콘만 사용하지 말고 눈에 보이는 단어를 사용하십시오. "AI 지원 탐지 결과(AI-assisted finding)"는 반짝이는 아이콘보다 더 명확합니다. "제안된 자동 수정(Proposed Autofix)"은 "수정됨(Fixed)"보다 더 명확합니다. 포커스 가능한 pre 태그를 사용하면 키보드 사용자가 긴 패치(patch)를 스크롤할 수 있지만, 실제 구현에는 줄 단위의 추가/삭제 기능과 일반 텍스트 대체(plain-text fallback) 기능도 필요합니다.

상태 동작(State behavior)

개수는 정중하게 알리고, 저장 중일 때는 짧게, 실패했을 때는 단호하게 알리며, 해결(resolution) 시에는 전체 패치를 읽지 않고 알리십시오. 확장 후에는 트리거 컨트롤(triggering control)에 포커스를 유지하고, 실패 후에는 에러 요약(error summary)으로 포커스를 이동하며, 카드가 사라지면 다음 카드로 포커스를 이동시키십시오.

정상 경로 (Normal path): 검토자가 출처(origin)별로 필터링하고, 증거(evidence)를 열고, 패치(patch)를 검사하며, 결정을 선택하면 포커스가 예기치 않게 이동하지 않고 지속적인 확인(durable confirmation)을 받습니다.

실패 경로 (Failure path): 저장 시 에러가 반환되거나 탐지 결과의 리비전(finding revision)이 변경된 경우입니다. 선택 사항을 로컬에 유지하고, 해당 레코드를 오래된 것(stale)으로 표시하며, 연결된 에러 요약(error summary)에 포커스를 맞추고, 새로운 패치를 다시 검토하도록 요구하십시오. 변경된 Autofix에 대해 이전의 승인(acceptance)을 절대 제출하지 마십시오.

리비전 인지 요청(revision-aware request)은 다음과 같을 수 있습니다:

{
  "findingId": "f-17",
  "findingRevision": 3,
...

서버는 리비전이 일치하지 않으면 409 Conflict로 거부합니다. 그러면 인터페이스는 “제안된 수정 사항이 변경되었습니다. 다시 검토하십시오.”라고 안내하고, 새로운 증거를 확장하며, 결정을 설정되지 않은 상태로 둡니다.

접근성 QA (Accessibility QA)

키보드 순서 및 트랩(traps), 스크린 리더 레이블(screen-reader labels), 400% 리플로우(reflow), 동작 감소(reduced motion), 고대비 상태 큐(high-contrast status cues)를 테스트하십시오. 브라우저, OS, 보조 기술 및 버전을 기록하십시오. 이 제안된 매트릭스는 실행되지 않았습니다.

릴리스 체크리스트:

• 결정론적(deterministic) 출처와 AI 보조(AI-assisted) 출처를 텍스트로 노출하십시오.
• 심각도(severity), 신뢰도(confidence), 출처(provenance), 결정(decision)을 별도의 필드로 유지하십시오.
• Autofix가 수락되기 전에 명시적인 검토를 요구하십시오.
• 결정을 패치 해시(patch hash) 또는 탐지 결과 리비전(finding revision)에 바인딩하십시오.
• 사유와 함께 거부(reject-with-reason) 기능 및 저장 실패 후 재시도(retry)를 지원하십시오.
• 카드를 정렬하거나 제거할 때 포커스를 유지하십시오.
• 현재 플랜 가용성 및 제품 동작을 확인하십시오.

한계: 이 컴포넌트는 CodeQL 의미론(semantics), 탐지 정확성, WCAG 준수 또는 GitHub UI 동작을 확립하지 않습니다. 매우 큰 패치의 경우 카드 뷰가 불충분할 수 있으므로 전체 디프(full diff)를 제공하십시오. 제품 레이블 및 가용성은 변경될 수 있습니다.

다른 곳에서도 동일한 UI 규율을 평가하십시오

이러한 상태들이 정의된 후 MonkeyCode를 평가할 수 있습니다. 검증된 자료에 따르면, MonkeyCode는 오픈 소스 AGPL-3.0 AI 개발 플랫폼, 해외 온라인 옵션, 관리형 서버 측 클라우드 개발 환경, 모델/태스크/요구사항 관리, 그리고 빌드/테스트/미리보기를 제공하며 무료로 시작할 수 있습니다. 저는 해당 인터페이스를 테스트하지 않았습니다. 만약 귀하의 후보 목록에 적합하다면, 접근성(accessibility)을 가정하기보다는 공식 캠페인 경로를 사용하고 키보드, 오래된 리비전(stale-revision), 그리고 실패 리뷰(failure review)를 반복하십시오.

공개 고지: 이 기사는 공식 캠페인 링크를 사용하여 MonkeyCode를 홍보합니다. 저는 MonkeyCode 사용자이며, 프로젝트와 관련이 없으며, 이 링크를 통해 어떠한 수수료도 받지 않습니다.

AI 지원 공개: 이 기사는 AI의 지원을 받아 초안이 작성되었으며, 인용된 기본 출처를 바탕으로 검토되었습니다.