AI 에이전트가 테스트 실패 후 자신의 계획(Plan)을 수정합니다. 만약 인터페이스가 기존 텍스트를 조용히 교체해 버린다면, 검토자(Reviewer)가 새로운 도구 권한이 나타났음을 알 수 있을까요?

모든 수정 사항을 새로 고침된 단락이 아닌, 버전이 지정된 차이점(diff)으로 취급하세요:

type PlanVersion = {
  id: number;
  added: Step[];
...

리뷰 영역에는 논리적인 제목(heading), 요약(summary), 그리고 초점 순서(focus order)가 필요합니다:

<h2 id="plan-title">Plan revision 3</h2>
<p role="status">2 steps added; terminal access expanded.</p>
<section aria-labelledby="plan-title">...</section>
...

수정 사항이 도착했을 때 초점(focus)을 자동으로 이동시키지 마세요. 상태를 알리고, 검토자의 위치를 보존하며, 변경 요약으로 이동할 수 있는 단축키를 제공하세요. 만약 revision 3이 열려 있는 동안 revision 4가 도착한다면, 유효하지 않은(stale) 승인 버튼을 비활성화하고 그 이유를 설명하세요. 추가, 삭제 또는 권한 변경을 나타내는 유일한 신호가 색상(Color)이 되어서는 안 됩니다. 검토자가 작성 중인 초안 댓글을 무효화 과정 중에도 저장하여, 안전을 위한 조치가 신중한 피드백을 방해하지 않도록 하세요.

role="status"에 대한 W3C 기술은 초점을 뺏지 않고도 상태 업데이트를 어떻게 노출할 수 있는지 보여줍니다. 이는 패턴의 일부일 뿐이며, 키보드 내비게이션(keyboard navigation), 의미론적 차이점 레이블(semantic diff labels), 취소(cancellation), 그리고 스크린 리더(screen-reader) 테스트는 여전히 명시적인 QA가 필요합니다.

이 컴포넌트는 MonkeyCode와 같은 장시간 실행되는 코딩 플랫폼을 위한 외부 수락 패턴(acceptance pattern)으로 활용될 수 있습니다. 해당 프로젝트의 클라우드 서비스는 현재 무료로 시작할 수 있어 일회성 브라우저 흐름 리뷰가 가능하지만, 이 글이 해당 서비스의 현재 UI가 이러한 동작을 갖추고 있다거나 갖추지 못하고 있다고 주장하는 것은 아닙니다.

저는 MonkeyCode 사용자이며, 해당 프로젝트와 관련이 없습니다. 이 계정은 다른 배치 계정들과 운영자가 동일합니다.